Linker problems with system vs bundled libraries (RPATH vs RUNPATH)

Luboš Luňák l.lunak at collabora.com
Fri Jan 25 12:08:51 UTC 2019


On Friday 25 of January 2019, Stephan Bergmann wrote:
> On 24/01/2019 21:36, Luboš Luňák wrote:
> >   Basically, the problem seems to be a variant of
> > http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/ . In the build log
> > (https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/22968/consoleF
> >ull#12040746019567f988-cbcf-4519-af05-6000b834f13f) there is an error
> > message
> > about "...instdir/program/soffice.bin: /lib64/libgpg-error.so.0: no
> > version information available (required  by
> > ...instdir/program/libgpgme.so.11)". But our libgpgme shouldn't be using
> > system libgpg-error, they're both bundled.
>
> Are you sure that those "no version information available" lines are
> actually hard errors that make the process (and thus the test) fail, not
> merely warnings (and the tests fail for another reason; I've seen such
> undecipherable UITest failures sporadically, too)?

 No, those messages are not the errors that cause the failures, I listed it to 
show that the system lib is used even though there's the bundled one.

 The actual hard error should be the one a couple of lines 
later: "instdir/program/soffice.bin: relocation 
error: ...instdir/program/libgpgme.so.11: symbol gpgrt_lock_lock, version 
GPG_ERROR_1.0 not defined in file libgpg-error.so.0 with link time reference"

 In other words, the (system) libgpg-error used at runtime is older then the 
(bundled) libgpg-error that was used during the build and doesn't have a 
necessary symbol. And presumably that system libgpg-error would be too old 
even during the build, at least I tried that in patchset #4 of gerrit#65426 
and the build failed during compilation.

-- 
 Luboš Luňák
 l.lunak at collabora.com


More information about the LibreOffice mailing list