Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
l.lunak at collabora.com
Thu Jan 24 20:36:02 UTC 2019
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
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?
l.lunak at collabora.com
More information about the LibreOffice