Re: Linker problems with system vs bundled libraries (RPATH vs RUNPATH) / LTO / gold
Hello, my initial understanding of the case “Linker problems with system vs bundled libraries (RPATH vs RUNPATH) ” is, that ld.bfd and ld.gold behave differently, which is exposed by invoking --enable-linker= How do ld.bfd and ld.gold differ, that triggered the problem? Based on what does ./configure --help print behind --enable-lto: best used with “gold”. Are there any known problems with ld.bfd? The "gold as linker" in configure.in/configure.ac comes from commit fc41132306 back in 2011 and ld.bfd can handle linker plugins at least since 2015. The AS_HELP_STRING for --enable-lto says "both gold and lld linkers generally use less memory and link faster". Compared to what? It shoud say "compared to ld.bfd". --enable-lto switches AR, NM and RANLIB to be gcc-ar, gcc-nm and gcc-ranlib, but… on some systems the binary is called gcc-ar-4, for clang you have to use llvm-ar, which on some systems is called llvm-ar-5.0. I am not aware of a single autoconf project that manages this right; new versions of CMake do. I propose removing all the LTO extras from LibreOffice. Competent users are supposed to install the linker plugin liblto_plugin.so and LLVMgold.so in $libdir/bfd-plugins and insert -flto into CFLAGS and CXXFLAGS, respectively -flto=6 in LDFLAGS. Incompetent users don’t have a problem without LTO, as they do not know LTO exists. Regards Дилян On Fri, 2019-02-01 at 21:32 +0100, Michael Stahl wrote: > On 01.02.19 20:12, Luboš Luňák wrote: > > On Monday 28 of January 2019, Michael Stahl wrote: > > > hope this will help: > > > > > > https://gerrit.libreoffice.org/#/c/67012/ > > > > > > the idea is we use different symbol version for everything so LO libs > > > call into bundled library, system libs call into system library. > > > > > > haven't tested it though, just make check runs fine here... > > > > Yes, that works. But before you do, could you please e.g. add URL of this > > discussion to the commit message? "unintended hilarity" is a rather poor > > problem description. > > ... unfortunately it's too late to add anything to the commit message as > the patch somehow reviewed and pushed itself. > > well, anybody who knows what a gloriously misguided idea the ELF global > namespace is can think of any number of problems that would be fixed by > the patch :) > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/libreoffice ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
On 01.02.19 20:12, Luboš Luňák wrote: On Monday 28 of January 2019, Michael Stahl wrote: hope this will help: https://gerrit.libreoffice.org/#/c/67012/ the idea is we use different symbol version for everything so LO libs call into bundled library, system libs call into system library. haven't tested it though, just make check runs fine here... Yes, that works. But before you do, could you please e.g. add URL of this discussion to the commit message? "unintended hilarity" is a rather poor problem description. ... unfortunately it's too late to add anything to the commit message as the patch somehow reviewed and pushed itself. well, anybody who knows what a gloriously misguided idea the ELF global namespace is can think of any number of problems that would be fixed by the patch :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
On Monday 28 of January 2019, Michael Stahl wrote: > hope this will help: > > https://gerrit.libreoffice.org/#/c/67012/ > > the idea is we use different symbol version for everything so LO libs > call into bundled library, system libs call into system library. > > haven't tested it though, just make check runs fine here... Yes, that works. But before you do, could you please e.g. add URL of this discussion to the commit message? "unintended hilarity" is a rather poor problem description. -- Luboš Luňák l.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
On 25.01.19 15:06, Luboš Luňák wrote: On Friday 25 of January 2019, Miklos Vajna wrote: On Fri, Jan 25, 2019 at 01:08:51PM +0100, Luboš Luňák wrote: 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 DLP libs had this problem as well, and these days we just patch the externals to have a different .so name, see e.g.: external/libodfgen/libodfgen-bundled-soname.patch.0 (Other DLP libs are built statically.) Would it be an option to do the same for the GPG stuff? I'm not sure. That'd make soffice.bin load both instances of the lib, which would solve the problem of some symbols missing. But having two different versions of the same lib could possibly also cause clashes between them, since ELF interposition could make e.g. libgpgme bind some symbols to the system lib and other to the bundled lib (I've actually tried that, see the attachment). Which we could either ignore (I don't know likely is that to cause a real problem) or we'd need to namespace/version the whole library (which I don't know how much work that'd be). hope this will help: https://gerrit.libreoffice.org/#/c/67012/ the idea is we use different symbol version for everything so LO libs call into bundled library, system libs call into system library. haven't tested it though, just make check runs fine here... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
On Friday 25 of January 2019, Miklos Vajna wrote: > On Fri, Jan 25, 2019 at 01:08:51PM +0100, Luboš Luňák wrote: > > 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 DLP libs had this problem as well, and these days we just patch the > externals to have a different .so name, see e.g.: > > external/libodfgen/libodfgen-bundled-soname.patch.0 > > (Other DLP libs are built statically.) > > Would it be an option to do the same for the GPG stuff? I'm not sure. That'd make soffice.bin load both instances of the lib, which would solve the problem of some symbols missing. But having two different versions of the same lib could possibly also cause clashes between them, since ELF interposition could make e.g. libgpgme bind some symbols to the system lib and other to the bundled lib (I've actually tried that, see the attachment). Which we could either ignore (I don't know likely is that to cause a real problem) or we'd need to namespace/version the whole library (which I don't know how much work that'd be). In the case of libgpg-error, I still think upgrading the system lib should be the simplest and best option. If I'm not mistaken, the system used for Jenkins build is some CentOS version with quite old software (LO can't be even built using its libgpg-error), so in the case of this specific library people shouldn't generally run into this problem anyway. -- Luboš Luňák l.lu...@collabora.com test_duplicated_lib.tar.gz Description: application/tgz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
Hi Lubos, On Fri, Jan 25, 2019 at 01:08:51PM +0100, Luboš Luňák wrote: > 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 DLP libs had this problem as well, and these days we just patch the externals to have a different .so name, see e.g.: external/libodfgen/libodfgen-bundled-soname.patch.0 (Other DLP libs are built statically.) Would it be an option to do the same for the GPG stuff? Regards, Miklos signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
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.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
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/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. 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)? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Linker problems with system vs bundled libraries (RPATH vs RUNPATH)
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.lu...@collabora.com ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
