[Bug regression/33637] New: "checking for nm: test: too many arguments" causes "Undefined symbol: __gxx_personality_v0"

haubi at gentoo dot org gcc-bugzilla@gcc.gnu.org
Wed Oct 3 12:42:00 GMT 2007


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



More information about the Gcc-bugs mailing list