https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sci-misc/boinc fails to link with LLD because of /usr/lib in the link command line. Discovered on: amd64 (internal ref: tinderbox) NOTE: This PR gives an idea about a fix: https://github.com/PhotoFlare/photoflare/pull/248/files.
Created attachment 648718 [details] build.log build log and emerge --info
Created attachment 648720 [details] other.tar.bz2 other logs
Thanks for the information! I've got a new laptop and haven't boinc set up, yet. That should be updated anyway, so I'll look into that.
There is something odd in the build.log: -------- /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../lib64/crt1.o is incompatible with elf_x86_64 -------- I have that file with gcc-9.3.0 and iot says: -------- ~ $ file /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../lib64/crt1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), for GNU/Linux 3.2.0, not stripped -------- So, according to your log, ldd says that "ELF 64-bit" is incompatible with elf_x86_64 ? I'll check for hardcoded paths, but could you please check your box?
Actually what you are complaining about is an upstream bug. See: https://bugs.llvm.org/show_bug.cgi?id=42802 I'll try to get rid of the wrong library paths, but actually we should not do this. The BOINC build system is very complex, and it is LDD that is doing wrong here. The Blocker is the only reason why I do not mark this as WONTFIX.
*** Bug 741588 has been marked as a duplicate of this bug. ***
Created attachment 670826 [details, diff] Disable explicit library search paths for lglu32, lglut32
Created attachment 670829 [details, diff] Disable explicit library search paths for libssl
The issue is that configure checks for libssl (and non-critical lglu32/lglut32) prepend additional library search paths, -L/usr and -L/usr/lib, which are 32-bit search paths, but we're building a 64-bit project. When -lcurl is checked, SSL_LIBS gets also appended as part of the test, and fails. Since we're running autotools at the beginning of the ebuild anyway, we can patch the m4/*.m4 files, have them regenerated right after patching and have the build work again. According also to the upstream bug, it seems that ld.bfd and ld.gold happily ignore the non-matching files in the wrong search paths, while ld.lld actually complains (in my opinion, a saner behavior). By dropping the attached two patches in /etc/portage/patches, I can finally build boinc properly.
Thanks alot. The first patche is already in my PR, but I missed the check_ssl.m4 issue. I will update my PR now.
PR edited. Please note that it is a PR to bump to boinc-7.16.11
(In reply to Fabio Scaccabarozzi from comment #9) > According also to the upstream bug, it seems that ld.bfd and ld.gold happily > ignore the non-matching files in the wrong search paths, while ld.lld > actually complains (in my opinion, a saner behavior). No. Just no. ld.bfd and ld.gold do complain and go on searching for a match. ld.lld breaks off without even looking at alternatives, although there are paths left to check. If the behavior of ld.lld was sane, then -------- ~ # find /usr/lib /usr/lib64 -name 'libkms.so' /usr/lib/libkms.so /usr/lib64/libkms.so -------- must not show the match in /usr/lib64 either. But it does. Which is actually the purpose of searching&finding. I do not know what the rationale on breaking off the search by ld.lld is, but it is causing a lot of trouble without a single advantage in return.
(In reply to Sven Eden from comment #12) > I do not know what the rationale on breaking off the search by ld.lld is, > but it is causing a lot of trouble without a single advantage in return. Having thought it through some more, I think you're correct, it is *not* saner behavior. I tried to make up a case where you'd want to completely prevent linking if an incompatible library is found first, but couldn't think of any. I'll try and see if I can come up with a patch for LLD to submit to the upstream bug tracker.
Quick update: spent 3-4h poking at it, but the LLD code is much more complex than anticipated, and checking of the format of the object files happens after the full file paths are detected (couldn't find a trivial way to plug it in). I have updated the upstream bug with the code and archive to reproduce as was already requested.
Upstream bug was closed as RESOLVED-WONTFIX. I do agree with them that is boinc's build system being broken here (it's explicitly passing the wrong folder, and we should upstream those fixes also), on the other hand I still agree that the search&find behavior of LLD is worse than BFD's...
(In reply to Fabio Scaccabarozzi from comment #15) > Upstream bug was closed as RESOLVED-WONTFIX. I already thought it would... > I do agree with them that is boinc's build system being broken here (it's > explicitly passing the wrong folder, and we should upstream those fixes > also) Yes, that is a good idea. See: https://github.com/BOINC/boinc/issues/4095
Upstream asked me to PR our patch, so here we go: https://github.com/BOINC/boinc/pull/4099
(In reply to Sven Eden from comment #17) > Upstream asked me to PR our patch, so here we go: > https://github.com/BOINC/boinc/pull/4099 It got merged. :-)
Unfortunately the Fix did not make it into 7.16.14, so our patch will have to stay for now.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9b2020e1f608225d8fd30a16b4b7a1dcb9f214f commit e9b2020e1f608225d8fd30a16b4b7a1dcb9f214f Author: Sven Eden <sven.eden@prydeworx.com> AuthorDate: 2020-11-08 14:21:41 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2021-01-18 13:37:24 +0000 sci-misc/boinc: V7.16.14 bump, EAPI 7 upgrade, bug fixes, GLEP 81 This version bump also fixes the following issues: * The user/group management is now done according to GLEP 81 * /etc/init.d/boinc: Ensure correct RUNTIMEDIR permissions (#684074) * /etc/init.d/boinc: The password does no longer need to be submitted * Hardcoded library search paths to /lib and /usr/lib have been removed or switched to /lib64 and /usr/lib64, if those are the regular library directories on the emerging system. (#732024) Closes: https://bugs.gentoo.org/684074 Closes: https://bugs.gentoo.org/717580 Closes: https://bugs.gentoo.org/732024 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Sven Eden <sven.eden@prydeworx.com> Signed-off-by: Joonas Niilola <juippis@gentoo.org> sci-misc/boinc/Manifest | 1 + sci-misc/boinc/boinc-7.16.14.ebuild | 205 +++++++++++++++++++++ sci-misc/boinc/files/boinc-7.16-fix_webview.patch | 11 ++ .../boinc/files/boinc-7.16-remove-usr_lib.patch | 89 +++++++++ sci-misc/boinc/files/boinc.init.in | 53 +----- sci-misc/boinc/metadata.xml | 44 +++-- 6 files changed, 342 insertions(+), 61 deletions(-)
