Created attachment 383968 [details] Build log emerge -1 =net-analyzer/hydra-8.0 fails to build on amd64. [...] /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libncp.a(ncplib.o): relocation R_X86_64_32S against `.rodata.newshuffle' can not be used when making a shared object; recompile with -fPIC /usr/lib/libncp.a: could not read symbols: Bad value collect2: error: ld returned 1 exit status make: *** [hydra] Error 1
Created attachment 383970 [details] emerge --info
According to the output, configure script checks (and finds) a shared libncp, yet a static one gets used in linking... So: - does that configure script have a log ? - is that shared libncp somehow broken ?
Unmerging net-fs/ncpfs allows hydra to be built with no problems. But somehow hydra can't be built with current ncpfs. So the following fails with the same error: USE="ncp" emerge -1 =net-analyzer/hydra-8.0
(In reply to Chema Alonso from comment #3) > Unmerging net-fs/ncpfs allows hydra to be built with no problems. > > But somehow hydra can't be built with current ncpfs. So the following fails > with the same error: > > USE="ncp" emerge -1 =net-analyzer/hydra-8.0 Again, look for the log of that configure script.
(In reply to Rafał Mużyło from comment #4) > Again, look for the log of that configure script. It isn't autotools based. With net-fs/ncpfs-2.2.6-r2 installed, I see a dead symlink from /usr/lib64/libncp.so -> libncp.so.2.3 so ld gladly uses the static library instead and then runs into trouble.
(In reply to Jeroen Roovers from comment #5) > (In reply to Rafał Mużyło from comment #4) > > Again, look for the log of that configure script. > > It isn't autotools based. Irrelevant, even most of homebrew configure scripts have some logging facility and this output doesn't look homebrew. > > With net-fs/ncpfs-2.2.6-r2 installed, I see a dead symlink from > /usr/lib64/libncp.so -> libncp.so.2.3 so ld gladly uses the static library > instead and then runs into trouble. Now, this is a different matter. Is this symlink a preserved one or one actually installed by net-fs/ncpfs ? Does net-fs/ncpfs install a shared libncp ?
(In reply to Rafał Mużyło from comment #6) > Irrelevant, even most of homebrew configure scripts have some logging > facility and this output doesn't look homebrew. It's obvious that you haven't looked into it. Could you please take your bad advice elsewhere? > > With net-fs/ncpfs-2.2.6-r2 installed, I see a dead symlink from > > /usr/lib64/libncp.so -> libncp.so.2.3 so ld gladly uses the static library > > instead and then runs into trouble. > > Now, this is a different matter. > Is this symlink a preserved one or one actually installed by net-fs/ncpfs ? > Does net-fs/ncpfs install a shared libncp ? Again, you appear to have no idea what you are talking about.
(In reply to Jeroen Roovers from comment #7) > (In reply to Rafał Mużyło from comment #6) > > Irrelevant, even most of homebrew configure scripts have some logging > > facility and this output doesn't look homebrew. > > It's obvious that you haven't looked into it. Could you please take your bad > advice elsewhere? > Please tell me exactly which of my comments were wrong ? Yes, I'm starting with the general case, cause as long as the receiving party can be presumed to understand, it should be able to adapt the general advice to its specific case (cmake, scons, etc. (even waf) don't have config.log, yet they do have some way of logging its tests). > > > With net-fs/ncpfs-2.2.6-r2 installed, I see a dead symlink from > > > /usr/lib64/libncp.so -> libncp.so.2.3 so ld gladly uses the static library > > > instead and then runs into trouble. > > > > Now, this is a different matter. > > Is this symlink a preserved one or one actually installed by net-fs/ncpfs ? > > Does net-fs/ncpfs install a shared libncp ? > > Again, you appear to have no idea what you are talking about. (on somewhat related note, HOMEPAGE of ncpfs ebuild timeouts right now) No, I simply assume it's faster to check if the things are in order on *reporter's* side, as even looking at the buildsystem/ebuild doesn't cover al possible failure points. As the build system of ncpfs isn't libtool based, but simply assumes gcc compatible syntax, the symlinks to the lib are created by ldconfig run...that is if it that was not explicitly disabled in the ebuild. So, any symlinks are created in the ldconfig refresh phase by portage. Though (IIRC), ldconfig creates only on SONAME base (which here is libncp.so.2.3), so libncp.so seems to come from other place.
(In reply to Rafał Mużyło from comment #8) > Please tell me exactly which of my comments were wrong ? No. The problem is obvious: it's in the non-autotools based ./configure script, and you're not being helpful at all.
The automagic in the hydra configure script should be fixed with regard to NCP. Arch teams, please test and mark stable: =net-fs/ncpfs-2.2.6-r3 Targeted stable KEYWORDS : amd64 ppc ppc64 x86
(In reply to Jeroen Roovers from comment #10) > The automagic in the hydra configure script should be fixed with regard to > NCP. > It's not automagic that was the problem here - it was the problem fixed by ncpfs-2.2.6-makefile-fix-soname-link.patch (which was...creating libncp.so pointing at libncp.so.2.3.0).
Mind, I'm now aware net-analyzer/hydra configure script was more primitive than I initially assumed, but let me as you this: how does PKG_CHECK_MODULES checks if the lib it detects is in any way usable ?
(In reply to Rafał Mużyło from comment #12) > Mind, I'm now aware net-analyzer/hydra configure script was more primitive > than I initially assumed, but let me as you this: how does PKG_CHECK_MODULES > checks if the lib it detects is in any way usable ? Could you please please stop adding more noise?
amd64 stable
ppc stable
x86 stable
Stable for PPC64. Closing.