Some gnome packages does not respect $NM, I'm attaching an example where grep find the issue. These packages should use system's NM
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
