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