This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: current cygwin failure analysis
- From: Brian Dessent <brian at dessent dot net>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Thu, 07 Jun 2007 17:07:48 -0700
- Subject: Re: current cygwin failure analysis
- References: <9f71cef00706070741u468d6declc3fe8dbb809ca8ef@mail.gmail.com>
- Reply-to: libstdc++ at gcc dot gnu dot org
Benjamin Kosnik wrote:
/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/include/ext/codecvt_specializations.h:203:
> undefined reference to `_libiconv_close'
>
> [...]
>
> Which is weird, because:
>
> /usr/local/src/trunk/objdir/./gcc/g++ -shared-libgcc
> -B/usr/local/src/trunk/objdir/./gcc -nostdinc++
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src/.libs
> -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/
> -isystem /usr/local/i686-pc-cygwin/include -isystem
> /usr/local/i686-pc-cygwin/sys-include -g -O2 -D_GLIBCXX_ASSERT
> -fmessage-length=0 -g -O2 -DLOCALEDIR="." -nostdinc++
> -I/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
> -I/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/include
> -I/usr/local/src/trunk/gcc/libstdc++-v3/libsupc++
> -I/usr/local/src/trunk/gcc/libstdc++-v3/include/backward
> -I/usr/local/src/trunk/gcc/libstdc++-v3/testsuite/util
> -Wl,--gc-sections -liconv
> /usr/local/src/trunk/gcc/libstdc++-v3/testsuite/ext/enc_filebuf/char/13189.cc
> -include bits/stdc++.h ./libtestc++.a -o ./13189.exe
>
> is the command line, and -liconv is passed. Maybe there needs to be a
> -L flag for the location of libiconv?
>
> What's weird is that these test files have:
>
> // { dg-require-iconv "ISO-8859-1" }
>
> at the top, so if iconv functions cannot be found, they should not be run.
>
> Hmmm. Something's wrong with this config....
In this case it looks like just an argument ordering problem. It would
have said "unable to find -liconv" if that was the case, but instead
what's happening is that the linker processes -liconv before it's seen
any objects that use functions from it, and so it doesn't pull in any
symbols from it -- even though -liconv is a shared lib. (This is one of
the differences between PE and ELF that comes up again and again without
fail in porting to Windows.) Simply reordering the command ought to
work fine.
Brian