[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool cvs: AC_PROG_NM -B when build!=host
From: |
Kevin Ryde |
Subject: |
Re: libtool cvs: AC_PROG_NM -B when build!=host |
Date: |
Sun, 03 Feb 2002 08:47:42 +1000 |
User-agent: |
Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu) |
I posted this previously, so apologies for the duplication, but I
think the problem still exists.
When doing a cross compile, AC_PROG_NM will fall back on plain "nm" if
it can't find an "${ac_tool_prefix}nm". However in this case it
doesn't try to add -B or -p to select BSD format. This is not good
for instance on OSF when doing a "cross compile" from say alpha ev5 to
ev6 and using the ordinary system nm.
The problem can be seen with a minimal configure.in
AC_PREREQ(2.50)
AC_INIT(configure.in)
AC_PROG_CC
AC_PROG_LIBTOOL
and the usual
libtoolize
aclocal
autoconf
Running on OSF system
./configure --host=alphaev5-dec-osf5.1 --host=alphaev6-dec-osf5.1
gives
...
checking for BSD-compatible nm... nm
whereas I hoped it might give "/usr/bin/nm -B" as it does for a
"native" build.
I have to confess to not actually spotting any breakage in libtool
itself from a bad nm, though presumably $global_symbol_pipe etc
wouldn't work too well.
I hoped to have it in the right mode for the benefit of GMP, which
greps nm output for some assembler feature tests, like whether .align
is logarithmic, and a good local label prefix.
I'd like to suggest the change below to add an extra loop testing
first $ac_tool_prefix then an unprefixed nm. I've left the
indentation unchanged to keep the diff to the pertinent part.
* libtool.m4 (AC_PROG_NM): Try plain "nm" if "${ac_tool_prefix}nm" is
not found, for the benefit of cross compiles using the native "nm".
libtool.m4.prefixed-nm.diff
Description: Source code patch
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: libtool cvs: AC_PROG_NM -B when build!=host,
Kevin Ryde <=