Bug 124219 - soffice won't launch because of missing symbol cairo_surface_get_device_scale
Summary: soffice won't launch because of missing symbol cairo_surface_get_device_scale
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.3.0 target:6.2.4
Keywords:
Depends on:
Blocks: Installer-Linux
  Show dependency treegraph
 
Reported: 2019-03-20 03:48 UTC by Paul
Modified: 2019-04-04 11:44 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul 2019-03-20 03:48:01 UTC
Command:

soffice --headless

Error:
/opt/libreoffice6.2/program/soffice.bin: /lib64/libdbus-1.so.3: no version information available (required by /opt/libreoffice6.2/program/libmergedlo.so)
/opt/libreoffice6.2/program/soffice.bin: symbol lookup error: /opt/libreoffice6.2/program/libmergedlo.so: undefined symbol: cairo_surface_get_device_scale

Linux (uname -a):
  Linux ip-172-30-2-127 4.14.77-70.59.amzn1.x86_64 #1 SMP Mon Nov 12 22:02:45 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Libs:
cairo.x86_64                            1.12.14-6.8.amzn1          @amzn-main
cups.x86_64                             1:1.4.2-67.21.amzn1        @amzn-main
cups-libs.x86_64                        1:1.4.2-67.21.amzn1        @amzn-main
glibc.x86_64                            2.17-222.173.amzn1         installed
glibc-common.x86_64                     2.17-222.173.amzn1         installed
libXinerama.x86_64                      1.1.2-2.7.amzn1            @amzn-main
dbus.x86_64                             1:1.6.12-14.28.amzn1       installed

In the same environment:
  Libre Office version 6.1.5.2 works
  Libre Office version 6.2.0.3 fails
  Libre Office version 6.2.1.2 fails
Comment 1 Julien Nabet 2019-03-20 20:47:58 UTC
I think the pb is due to 3c80f4880d0d3a8f7c71d76877efe234f4f3629c
Indeed, this function seems to exist only from CAIRO 1.14 and there's no test here.

For the test, could you try another rendering (gtk or gen one)?
To do this:
- open a term
- type "export SAL_USE_VCLPLUGIN=gen"
- launch soffice from this term
then give a new try.

Also, would it be possible you upgrade your cairo lib?

Indeed, https://www.cairographics.org seems available right now but when Googling a bit, it seems cairo 1.14 has been released in october 2014 (more than 4 years!)
What Linux distrib do you use?
How did you install LO?
Comment 2 Paul 2019-04-01 14:38:49 UTC
(In reply to Julien Nabet from comment #1)
> I think the pb is due to 3c80f4880d0d3a8f7c71d76877efe234f4f3629c
> Indeed, this function seems to exist only from CAIRO 1.14 and there's no
> test here.
> 
> For the test, could you try another rendering (gtk or gen one)?
> To do this:
> - open a term
> - type "export SAL_USE_VCLPLUGIN=gen"
> - launch soffice from this term
> then give a new try.
> 
> Also, would it be possible you upgrade your cairo lib?
> 
> Indeed, https://www.cairographics.org seems available right now but when
> Googling a bit, it seems cairo 1.14 has been released in october 2014 (more
> than 4 years!)
> What Linux distrib do you use?
> How did you install LO?
Hi Julien.

This is from a standard AWS (Amazon Web Services) Linux build.  

SAL_USE_VCLPLUGIN made no difference:

  [program]$ export SAL_USE_VCLPLUGIN=gen
  [program]$ ./soffice --headless
  /opt/libreoffice6.2/program/soffice.bin: /lib64/libdbus-1.so.3: no version information available (required by /opt/libreoffice6.2/program/libmergedlo.so)
  /opt/libreoffice6.2/program/soffice.bin: symbol lookup error: /opt/libreoffice6.2/program/libmergedlo.so: undefined symbol: cairo_surface_get_device_scale
  [program]$ env|grep SAL
  SAL_USE_VCLPLUGIN=gen

An update to cairo is not available in the "standard" AWS Linux environment.

LO was installed by downloading from the archives, then removing the "desktop" and "integration" RPMs then using rpm -i *.rpm

Is it possible to find out what version of cairo this Libre Office is built against?
Comment 3 Julien Nabet 2019-04-01 14:50:21 UTC
I don't know how to know Cairo version used for the LO build.

However, could you completely uninstall LO and use package management? (see https://docs.aws.amazon.com/en_us/AWSEC2/latest/UserGuide/managing-software.html)
Indeed, by using rpm directly, you bypass dependencies checkings.
Comment 4 Paul 2019-04-02 01:58:33 UTC
Are you saying NOT to install a specific version of Libre Office and instead use the platform default?  I was reporting this because it appears to be an accidentally introduced build issue.
Comment 5 Julien Nabet 2019-04-03 19:51:09 UTC
I'm saying that if you want to give a try to a build you must know how to check dependencies manually. (I don't know how to do this)
What's your libcairo2 version?

(just for the record mine is:
Package: libcairo2
Source: cairo
Version: 1.16.0-4
I use Debian testing updated today)
Comment 6 Julien Nabet 2019-04-03 19:58:07 UTC
Paul: sorry, forget my question about libcairo version.
It seems to me more a distribution pb now.
They propose a recent LO version with an old cairo lib.

Caolán: any thoughts about this one since you used this function from cairo?
Comment 7 Caolán McNamara 2019-04-04 08:49:43 UTC
this should be fixable with dlsym
Comment 8 Julien Nabet 2019-04-04 08:52:56 UTC
Caolán: thank you for your feedback. However, according to Paul's comment 2, it can be reproduced with SAL_USE_VCLPLUGIN=gen. I took a look at the code and don't understand why since there's guard #if CAIRO_VERSION >= CAIRO_VERSION_ENCODE(1, 14, 0)
Comment 9 Caolán McNamara 2019-04-04 09:28:32 UTC
The #if CAIRO_VERSION >= CAIRO_VERSION_ENCODE(1, 14, 0) guard is a compile time one, so if Paul built his own version of LibreOffice against the version of cairo he has, then it wouldn't compile the call to ...get_device_scale

But he's using one that was build against cairo 1.14.0 so the call exists in the binary he's trying to run.

I'm going to change that to code that looks up if ...get_device_scale exists at runtime, not just at buildtime
Comment 10 Commit Notification 2019-04-04 10:12:51 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/cb7ff6bc57b542a27f6bdcfcaacc2cdf66cdb456%5E%21

Resolves: tdf#124219 check at runtime for availability of cairo functions

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2019-04-04 11:43:10 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/0edf02fc88a444157713874686b1c7409a13f04c%5E%21

Resolves: tdf#124219 check at runtime for availability of cairo functions

It will be available in 6.2.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.