| Summary: | sys-devel/libtool: does not default to ${CHOST}-nm | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | trivial | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://lists.gnu.org/archive/html/libtool-patches/2013-04/msg00000.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 243502 | ||
|
Description
Agostino Sarubbo
2013-03-24 13:52:51 UTC
How are this "NM" problems solved? (it's the first time I see it :S) (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 OK, @gnome, probably we could also call it from gnome2.eclass, what do you think? 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. *** Bug 463330 has been marked as a duplicate of this bug. *** *** Bug 465558 has been marked as a duplicate of this bug. *** *** Bug 466016 has been marked as a duplicate of this bug. *** 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 $?
1
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 ...
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. 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 ... i've tested thunar now works correctly (since it calls elibtoolize) http://sources.gentoo.org/eclass/ELT-patches/target-nm/2.4.2?rev=1.1 http://sources.gentoo.org/eclass/libtool.eclass?r1=1.103&r2=1.104 |