Re: AC_PROG_NM when compiling for mingw

[Bruno Haible]

Peter Rosin wrote:
> > +  if test -n "$ac_tool_prefix" \
> > +     && { test "$build" = "$host" \
> > +          || { test "$build_os" = cygwin && test "$host_os" = mingw32; }; \
> > +        }; then
> >      lt_nm_to_check="$lt_nm_to_check nm"
> ...
> That will be wrong when Cygwin 1.7/gcc4 is released with proper
> cross tools for building mingw binaries, which should be
> Real Soon Now<tm>.

Can you please explain what will be wrong about it? The patch assumes that
the Cygwin 'nm' can be applied to object files created by gcc for mingw.
Will the names of the config triples be changed? Or will Cygwin gcc create
.o files in a different format than it currently does (with or without
"-mno-cygwin")?

> Until then, is the extra output really so bad?

It's not about the extra output. It's about the fact that the test does
not find the right 'nm' program and punts. I rely on 'nm' for making a
shared library namespace clean. In gettext and libunistring [1] I map
symbols that should not be visible from the library, for example
  #define mmalloca libunistring_mmalloca
  #define rpl_malloc libunistring_rpl_malloc
  #define freea libunistring_freea
  #define fseterr libunistring_fseterr
  ...
For doing this, I need to call "nm". If 'nm' is not found, the resulting
library exports symbols that can (and will likely) collide with symbols
of other libraries.

As explained in the previous mail, CC and CPPFLAGS are variables that
the user should pass to 'configure' when cross-compiling, but NM is not.

Bruno

[1] 
http://git.savannah.gnu.org/gitweb/?p=libunistring.git;a=commitdiff;h=d598f9e1e016735397e9dca53b436d13c6fb28f3