Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 462976 - sys-devel/libtool: does not default to ${CHOST}-nm
Summary: sys-devel/libtool: does not default to ${CHOST}-nm
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal trivial (vote)
Assignee: Gentoo's Team for Core System packages
: 463330 465558 466016 (view as bug list)
Depends on:
Blocks: tc-directly
  Show dependency tree
Reported: 2013-03-24 13:52 UTC by Agostino Sarubbo
Modified: 2013-05-04 05:24 UTC (History)
0 users

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


Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2013-03-24 13:52:51 UTC
Some gnome packages does not respect $NM, I'm attaching an example where grep find the issue. These packages should use system's NM
Comment 1 Pacho Ramos gentoo-dev 2013-03-24 18:22:31 UTC
How are this "NM" problems solved? (it's the first time I see it :S)
Comment 2 Agostino Sarubbo gentoo-dev 2013-03-24 18:24:50 UTC
(In reply to comment #1)
> How are this "NM" problems solved? (it's the first time I see it :S)

if the buildsystem uses $(NM), tc-getNM should work
Comment 3 Pacho Ramos gentoo-dev 2013-03-24 18:35:50 UTC
OK, @gnome, probably we could also call it from gnome2.eclass, what do you think?
Comment 4 SpanKY gentoo-dev 2013-04-27 05:23:19 UTC
so the summary is wrong (which ends up pointing this  out itself).  libtool *does* respect $NM just fine.  it just doesn't default to using the prefixed nm tool like it does with other packages.

pretty sure this will happen with any package using libtool symbol versioning.
Comment 5 SpanKY gentoo-dev 2013-04-27 05:23:45 UTC
*** Bug 463330 has been marked as a duplicate of this bug. ***
Comment 6 SpanKY gentoo-dev 2013-04-27 05:23:48 UTC
*** Bug 465558 has been marked as a duplicate of this bug. ***
Comment 7 SpanKY gentoo-dev 2013-04-27 05:23:50 UTC
*** Bug 466016 has been marked as a duplicate of this bug. ***
Comment 8 SpanKY gentoo-dev 2013-04-27 05:29:34 UTC
heh, and the answer is even more nuanced than that

it *does* look at ${CHOST}-nm, but the test it uses fails:
+ test -z /usr/bin
+ tmp_nm=/usr/bin/x86_64-pc-linux-gnu-nm
+ test -f /usr/bin/x86_64-pc-linux-gnu-nm
+ case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
++ /usr/bin/x86_64-pc-linux-gnu-nm -B /dev/null
++ sed 1q
+ lt_cv_path_NM='/usr/bin/x86_64-pc-linux-gnu-nm -B'
+ break

$ /usr/bin/x86_64-pc-linux-gnu-nm -B /dev/null 
/usr/bin/x86_64-pc-linux-gnu-nm: Warning: '/dev/null' is not an ordinary file
$ echo $?

eventually all nm variants fail and it just defaults to /usr/bin/nm.

testing just about every version of binutils i have installed (2.17 through 2.23 snapshots), they all fail this way.  so it's not something new ...
Comment 9 SpanKY gentoo-dev 2013-04-27 05:48:50 UTC
nm, that was a red herring.  there's already code in there to deal with this.

libtool will only default to `nm` when *not* cross-compiling.  this is still wrong, but it's not as bad as it otherwise seems.  so if you see the pattern:
libtool: link: /usr/bin/nm -B <objects> | <seds and stuff> | sort | uniq > exp
then just ignore the /usr/bin/nm call.  the exact pipeline might be diff between packages, but you get the idea.

i'll send a patch upstream for it.
Comment 10 SpanKY gentoo-dev 2013-05-01 16:20:18 UTC
this has been fixed upstream, but it's a bug that'll be with us for a while.  we can add an elibtoolize patch to deploy the fix to existing packages ...
Comment 11 SpanKY gentoo-dev 2013-05-04 05:24:01 UTC
i've tested thunar now works correctly (since it calls elibtoolize)