[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_PROG_NM when compiling for mingw
From: |
Peter Rosin |
Subject: |
Re: AC_PROG_NM when compiling for mingw |
Date: |
Fri, 24 Apr 2009 13:59:29 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
Den 2009-04-24 12:24 skrev 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")?
There will be one cygwin nm for dealing with cygwin binaries and one
for dealing with mingw binaries. They will be named as they are named
on all other systems, i.e. nm for the native one and i686-pc-mingw32-nm
for the cross tool. Yes, they might do the same thing, one might even
be a symlink to the other, but that's besides the point. When -mno-cygwin
is gone you should definitely use i686-pc-mingw32-nm when dealing with
mingw binaries.
Also, do we really need more special cases for cygwin/mingw?
Until then, is the extra output really so bad?
It's not about the extra output.
But your configure output indicates that both problems 1 and 2 has been
fixed in git master. Was that not the case? Have you checked if NM
is set by git master? Or do you base your statements on this line only:
checking for BSD- or MS-compatible name lister (nm)... no
> 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.
Ok.
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.
That's your interpretation. The configure message says "Some influential
environment variables". Some. Not "all", "every" or anything like that.
The message has a cursory sound to it, IMHO.
Cheers,
Peter
- AC_PROG_NM when compiling for mingw, Bruno Haible, 2009/04/23
- Re: AC_PROG_NM when compiling for mingw, Ralf Wildenhues, 2009/04/23
- Re: AC_PROG_NM when compiling for mingw, Ralf Wildenhues, 2009/04/25
- Re: AC_PROG_NM when compiling for mingw, Bruno Haible, 2009/04/25
- Re: AC_PROG_NM when compiling for mingw, Peter Rosin, 2009/04/27
- Re: AC_PROG_NM when compiling for mingw, Bruno Haible, 2009/04/27