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
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?
(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?
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.
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.
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)
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?
this should be fixable with dlsym
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)
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
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.
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.