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

[Luboš Luňák <l.lunak@xxxxxxxxxxxxx>]

 Hello,

 I've decided to finally switch the default on --enable-ld to make configure 
automatically pick the gold/lld linkers if available, as talked about around 
the end of summer. However, it turns out at least least the relevant Jenkins 
build fails with a linker different than the old ld.bfd. I think it's really 
just a problem with the unusual setup of the build system, but I still want 
to post it here, just in case somebody sees/knows something that I've missed. 
And of course, if it's really just a problem with the Jenkins box, it'd be 
nice if somebody fixed that.

 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/consoleFull#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.

 I cannot reproduce the problem locally, but what I think happens is this: 
Using "ldd -v soffice.bin" reveals that it ends up using libgpg-error at 
least two ways, one indirectly by (bundled) libgpgme, one indirectly by 
system libraries (dbus, etc.). But a process loads the library just once. 
This normally is not a problem, because apparently either on most systems 
both the system and bundled version can stand in for each other, or everybody 
is lucky enough to pull in the newer version. Except for that Jenkins box 
when it uses ld.gold, that is.

 I've looked into the problem, the Qt link above and other info I could find, 
and it seems the underlying issue cannot really be solved. Whatever we do, as 
long as there's any LO build that bundles a library that's also available as 
a system one, there's a risk of a case when the older one gets pulled in. You 
can read the Qt link for details on how RPATH and RUNPATH differ in searching 
for libraries, but in a nutshell: RPATH makes LO prefer our bundled libs, so 
there will be a problem if we bundle a lib that's too old for a system lib. 
RUNPATH makes LO prefer system libs when they are used by other system libs, 
so there will be a problem if the system lib is too old for our bundled lib 
(even if the bundled lib build fine against the bundled version of that 
relevant system lib).

 And that's presumably why the Jenkins build builds. It has old ld.bfd that 
still uses RPATH, and so LO picks up bundled libgpg-error and it works, but 
ld.gold uses RUNPATH, which leads to using the too-old system libgpg-error. I 
cannot reproduce the problem locally not only because my system libgpg-error 
is new enough, but also because on my system both ld.bfd and ld.gold use 
RUNPATH. That also means that just a newer linker on the Jenkins box would 
cause the same error, even without my patch.

 So, if I'm right, we basically can't entirely avoid the problem, and so the 
best course of action seems to be to shrug and not bother with these problems 
except for solving them as they appear (which, in this case, means updating 
libgpg-error on the Jenkins box). Does somebody have a better idea?

-- 
 Luboš Luňák
 l.lunak@xxxxxxxxxxxxx
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice