Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 521746 - =net-fs/ncpfs-2.2.6-r3 stable request
Summary: =net-fs/ncpfs-2.2.6-r3 stable request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Keywording and Stabilization (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Netmon project
URL:
Whiteboard: WAS: =net-analyzer/hydra-8.0 with net...
Keywords: STABLEREQ
Depends on: 522444
Blocks: 516966
  Show dependency tree
 
Reported: 2014-08-30 15:55 UTC by Chema Alonso Josa (RETIRED)
Modified: 2015-05-02 09:27 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Build log (hydra-8.0-build.log,34.19 KB, text/plain)
2014-08-30 15:55 UTC, Chema Alonso Josa (RETIRED)
Details
emerge --info (emerge-info,5.35 KB, text/plain)
2014-08-30 15:56 UTC, Chema Alonso Josa (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chema Alonso Josa (RETIRED) gentoo-dev 2014-08-30 15:55:49 UTC
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
Comment 1 Chema Alonso Josa (RETIRED) gentoo-dev 2014-08-30 15:56:19 UTC
Created attachment 383970 [details]
emerge --info
Comment 2 Rafał Mużyło 2014-08-31 18:48:22 UTC
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 ?
Comment 3 Chema Alonso Josa (RETIRED) gentoo-dev 2014-09-06 11:19:33 UTC
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
Comment 4 Rafał Mużyło 2014-09-06 11:33:31 UTC
(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.
Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-06 13:38:03 UTC
(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.
Comment 6 Rafał Mużyło 2014-09-06 15:41:00 UTC
(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 ?
Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-07 21:10:33 UTC
(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.
Comment 8 Rafał Mużyło 2014-09-08 09:47:26 UTC
(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.
Comment 9 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-08 10:35:54 UTC
(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.
Comment 10 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-08 11:45:19 UTC
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
Comment 11 Rafał Mużyło 2014-09-08 12:24:37 UTC
(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).
Comment 12 Rafał Mużyło 2014-09-08 12:41:05 UTC
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 ?
Comment 13 Jeroen Roovers (RETIRED) gentoo-dev 2014-09-08 13:26:15 UTC
(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?
Comment 14 Chema Alonso Josa (RETIRED) gentoo-dev 2014-09-09 18:54:56 UTC
amd64 stable
Comment 15 Agostino Sarubbo gentoo-dev 2015-03-02 09:40:34 UTC
ppc stable
Comment 16 Pacho Ramos gentoo-dev 2015-04-18 15:54:54 UTC
x86 stable
Comment 17 Jeroen Roovers (RETIRED) gentoo-dev 2015-05-02 09:27:52 UTC
Stable for PPC64. Closing.