bug#7698: aclocal generates too strict a check for name-lister

[Ximin Luo]

On 22/12/10 22:52, Peter Rosin wrote:
> Well, since I do not see any message on bug-libtool (yet), I'll respond here.
> 
> Your quoted "responsible snippet" is not really responsible, methinks.
> 
> The bug I mentioned was that when cross-compiling and yet expecting to find
> a name lister that is not named as cross tools are normally named (i.e.
> relying on 'nm' instead of 'pentium4-foo-bar-nm') libtool would go with the
> 'link' program instead of falling back to 'nm'. In the good old days, before
> libtool could use 'link' (not the 'link' you have, another proprietary 'link')
> to find symbols, libtool did fall back to 'nm' in setups such as yours,
> and that regression was fixed in 2.2.8. This is exactly what seems to be
> happening to you, so I can only encourage you to try with a more recent
> libtool. Or, if you find it difficult to update libtool, install a
> 'pentium4-foo-bar-nm' where your current libtool will find it, perhaps as a
> symlink to '/usr/bin/nm'.
> 
> Cheers,
> Peter

The full snippet (libtool.m4) is:

  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
    lt_nm_to_check="$lt_nm_to_check nm"
  fi

This fails for e.g. { build=i686-pc-linux-gnu host=i486-pc-linux-gnu }, or {
build=core2-pc-linux-gnu host=athlon64-pc-linux-gnu }, but this is too strict
and unnecessary, because they still use the same object file format.

(I'm not an expert in this area, so I may be wrong here, but from what I know,
I believe I'm right.)

(This is still true for libtool 2.2.10. The commit you made, `git show
032d3cc9c17b51649153f51c50d1586774799cbd`, aims to work around it in another
way, but I think my suggestion is a more "direct" fix to the problem.)

X

-- 
GPG: 4096R/5FBBDBCE