Sorry for the details - might not be required as I already tracked down the
problem to the source line...
When NM_FOR_TARGET requires arguments (fex "-B -X32_64" for aix), checking for
nm in gcc/configure{,.ac} is broken:
Assume
*) source is /source/gcc-4.2.0
*) builddir is /build
*) configured --prefix=/prefix (and others, but irrelevant)
checking what assembler to use... /usr/ccs/bin/as
checking what linker to use... /usr/ccs/bin/ld
/source/gcc-4.2.0/gcc/configure: line 13513: test: too many arguments
checking for powerpc-ibm-aix5.3.0.0-nm... /usr/bin/nm
checking what nm to use... /usr/bin/nm
checking for objdump... no
This only becomes a real problem, when there is some symlink or wrapper
available as "/prefix/${target}/bin/nm", or somehow else NM_FOR_TARGET already
contains full path.
checking what assembler to use... /prefix/powerpc-ibm-aix5.3.0.0/bin/as
checking what linker to use... /prefix/powerpc-ibm-aix5.3.0.0/bin/ld
/source/gcc-4.2.0/gcc/configure: line 13513: test: too many arguments
checking for /prefix/powerpc-ibm-aix5.3.0.0/bin/nm... no
checking what nm to use...
checking for objdump... no
So it ends up with no nm at all.
The follow-up problems are:
1) generated builddir/gcc/nm is (missing /path/to/nm)
#!/bin/sh
exec "$@"
2) while configuring powerpc-ibm-aix5.3.0.0/libstdc++-v3:
checking dynamic linker characteristics... aix5.3.0.0 ld.so
checking command to parse /build/./gcc/nm -B -X32_64 output... /build/./gcc/nm:
line 2: exec: -B: invalid option
exec: usage: exec [-cl] [-a name] file [redirection ...]
/build/./gcc/nm: line 2: exec: -B: invalid option
exec: usage: exec [-cl] [-a name] file [redirection ...]
failed
checking if libtool supports shared libraries... yes
3) The generated libstdc++.a does not export any symbols, because nm fails to
create a list of symbols due to 2).
4) When using g++, the simplest resulting linker error is
ld: 0711-317 ERROR: Undefined symbol: __gxx_personality_v0
'-bnoquiet' linker-output contains this line:
LIBRARY: Shared object libstdc++.a[libstdc++.so.6]: 0 symbols imported.
Looks like the same problem was here:
http://gcc.gnu.org/ml/gcc-help/2007-09/msg00100.html
The code around line 13513 in gcc-4.2.0/gcc/configure is:
13507 if test -f $gcc_cv_binutils_srcdir/configure.in \
13508 && test -f ../binutils/Makefile \
13509 && test x$build = x$host; then
13510 gcc_cv_nm=../binutils/nm-new$build_exeext
13511 elif test -x nm$build_exeext; then
13512 gcc_cv_nm=./nm$build_exeext
13513 elif test -x $NM_FOR_TARGET; then
^^^^^^^ broken ^^^^^^^
13514 gcc_cv_nm="$NM_FOR_TARGET"
13515 else
13516 # Extract the first word of "$NM_FOR_TARGET", so it can be a
program name with args.
13517 set dummy $NM_FOR_TARGET; ac_word=$2
13518 echo "$as_me:$LINENO: checking for $ac_word" >&5
This problem came up with gentoo-alt/prefix - still using native toolchain. but
wrapped with binutils-config - thus /prefix/${target}/bin/nm is available
(actually gentoo-alt/prefix configures with --prefix=/prefix/usr and builds
within some longer builddir - have it shortened here for readability).
Have already searched in gcc-svn:
This problem was introduced in revision 110266 of trunk/gcc/configure.ac, being
both in gcc-4.2-branch and trunk, but not gcc-4.1-branch.
What I'm unable to say is how to fix this correctly.
--
Summary: "checking for nm: test: too many arguments" causes
"Undefined symbol: __gxx_personality_v0"
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: haubi at gentoo dot org
GCC build triplet: powerpc-ibm-aix5.3.0.0
GCC host triplet: powerpc-ibm-aix5.3.0.0
GCC target triplet: powerpc-ibm-aix5.3.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33637
