[Bug libstdc++/16371] New: gcc 3.4.1 fails to configure on amd64 with multilib enabled

[Bug libstdc++/16371] New: gcc 3.4.1 fails to configure on amd64 with multilib enabled

[lv at gentoo dot org]

with multilib enabled on amd64, gcc 3.4.1 fails to configure libstdc++ for
32bit. the error i get is:

checking for sin in -lm... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.

a more complete version:

Adding multilib support to Makefile in ../../../gcc-3.4.1/libstdc++-v3
multidirs=32
with_multisubdir=
Running configure in multilib subdirs 32
pwd: /root/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3
Running configure in multilib subdir 32
pwd: /root/gcc/build/x86_64-unknown-linux-gnu
mkdir 32
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for x86_64-unknown-linux-gnu-gcc... /root/gcc/build/gcc/xgcc
-B/root/gcc/build/gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include  -m32
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /root/gcc/build/gcc/xgcc -B/root/gcc/build/gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include  -m32 accepts -g... yes
checking for /root/gcc/build/gcc/xgcc -B/root/gcc/build/gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include  -m32 option to accept ANSI C...
none needed
checking for x86_64-unknown-linux-gnu-g++... /root/gcc/build/gcc/xgcc
-shared-libgcc -B/root/gcc/build/gcc/ -nostdinc++
-L/root/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
-L/root/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include  -m32
checking whether we are using the GNU C++ compiler... yes
checking whether /root/gcc/build/gcc/xgcc -shared-libgcc -B/root/gcc/build/gcc/
-nostdinc++ -L/root/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
-L/root/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include  -m32 accepts -g... yes
checking for GCC version number... 3.4.1
checking whether ln -s works... yes
checking for x86_64-unknown-linux-gnu-as... as
checking for x86_64-unknown-linux-gnu-ar... ar
checking for x86_64-unknown-linux-gnu-ranlib... ranlib
checking whether to enable maintainer-specific portions of Makefiles... no
configure: CPU config directory is cpu/i486
configure: OS config directory is os/gnu-linux
checking for ld used by GCC... ld -m elf_x86_64
checking if the linker (ld -m elf_x86_64) is GNU ld... yes
checking for ld -m elf_x86_64 option to reload object files... -r
checking for BSD-compatible nm... nm
checking how to recognise dependant libraries... file_magic ELF [0-9][0-9]*-bit
[LM]SB (shared object|dynamic lib )
checking for x86_64-unknown-linux-gnu-file... no
checking for file... /usr/bin/file
checking for x86_64-unknown-linux-gnu-ranlib... (cached) ranlib
checking for x86_64-unknown-linux-gnu-strip... no
checking for strip... strip
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking whether -lc should be explicitly linked in... no
checking for objdir... .libs
checking for /root/gcc/build/gcc/xgcc option to produce PIC... -fPIC -DPIC
checking if /root/gcc/build/gcc/xgcc PIC flag -fPIC -DPIC works... yes
checking if /root/gcc/build/gcc/xgcc static flag -static works... no
finding the maximum length of command line arguments... 49153
checking if /root/gcc/build/gcc/xgcc supports -c -o file.o... yes
checking if /root/gcc/build/gcc/xgcc supports -fno-rtti -fno-exceptions ... no
checking whether the linker (ld -m elf_x86_64 -m elf_i386) supports shared
libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking command to parse nm output... failed
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
creating libtool
updating cache ./config.cache
configure: loading cache ./config.cache
checking how to run the C++ preprocessor... /root/gcc/build/gcc/xgcc
-shared-libgcc -B/root/gcc/build/gcc/ -nostdinc++
-L/root/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
-L/root/gcc/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include  -m32 -E
loading cache ./config.cache within ltconfig
checking host system type... x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking for objdir... .libs
checking for /root/gcc/build/gcc/xgcc option to produce PIC... -fPIC -DPIC
checking if /root/gcc/build/gcc/xgcc PIC flag -fPIC -DPIC works... yes
checking if /root/gcc/build/gcc/xgcc static flag -static works... no
finding the maximum length of command line arguments... (cached) 49153
checking if /root/gcc/build/gcc/xgcc supports -c -o file.o... (cached) yes
checking if /root/gcc/build/gcc/xgcc supports -fno-rtti -fno-exceptions ... yes
checking whether the linker (ld -m elf_x86_64 -m elf_i386) supports shared
libraries...
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking command to parse nm output... failed
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
appending configuration tag "CXX" to libtool
checking for exception model to use... call frame
checking for enabled PCH... yes
checking for compiler with PCH support... yes
checking for underlying I/O to use... stdio
checking how to run the C preprocessor... /root/gcc/build/gcc/xgcc
-B/root/gcc/build/gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include  -m32 -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for C locale to use... generic
checking for std::allocator base class to use... new
configure: "C" header strategy set to c_std
checking for ISO C99 support in <math.h>... yes
checking for ISO C99 support in <stdio.h>... yes
checking for lldiv_t declaration... yes
checking for ISO C99 support in <stdlib.h>... yes
checking for additional ISO C99 support in <wchar.h>... yes
checking for enabled ISO C99 support... yes
checking for enabled long long I/O support... yes
checking for thread model used by GCC... posix
configure: Debug build flags set to -g3 -O0
checking for additional debug build... no
checking for extra compiler flags for building...
checking nan.h usability... no
checking nan.h presence... no
checking for nan.h... no
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking endian.h usability... yes
checking endian.h presence... yes
checking for endian.h... yes
checking sys/isa_defs.h usability... no
checking sys/isa_defs.h presence... no
checking for sys/isa_defs.h... no
checking machine/endian.h usability... no
checking machine/endian.h presence... no
checking for machine/endian.h... no
checking machine/param.h usability... no
checking machine/param.h presence... no
checking for machine/param.h... no
checking sys/machine.h usability... no
checking sys/machine.h presence... no
checking for sys/machine.h... no
checking fp.h usability... no
checking fp.h presence... no
checking for fp.h... no
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking for inttypes.h... (cached) yes
checking gconv.h usability... yes
checking gconv.h presence... yes
checking for gconv.h... yes
checking for sys/types.h... (cached) yes
checking for g++ that supports -ffunction-sections -fdata-sections... yes
checking for sin in -lm... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make: *** [configure-target-libstdc++-v3] Error 1

-- 
           Summary: gcc 3.4.1 fails to configure on amd64 with multilib
                    enabled
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: lv at gentoo dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-05 16:31 -------
How did these testresults get generated then: <http://gcc.gnu.org/ml/gcc-testresults/2004-07/
msg00070.html>?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[lv at gentoo dot org]

------- Additional Comments From lv at gentoo dot org  2004-07-05 16:52 -------
good question. if you ever get the answer, let me know.

however, on my system, if i just configure gcc 3.4.1 without any additional
options it fails. on the exact same system 3.4.0 does not fail to configure and
compile... i've compiled my entire Gentoo GNU/linux install using gcc 3.4.0.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[lv at gentoo dot org]

------- Additional Comments From lv at gentoo dot org  2004-07-05 16:59 -------
err... that is, without any additional options other than --enable-multilib,
which i believe is the default anyways.

i would also like to note that the gentoo 20040601 snapshot of gcc 3.4.1 also
seems to work.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2004-07-05 17:02 -------
Indeed, today I also built 3.4.1 on x86_64 (multilib by default), no problem...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[lv at gentoo dot org]

------- Additional Comments From lv at gentoo dot org  2004-07-05 17:27 -------
oh boy. ok, i know very little about autotools... what information do I need to
figure out why this happens here? i'm currently using automake-1.8.5 and
autoconf-2.59, if that helps.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[lv at gentoo dot org]

------- Additional Comments From lv at gentoo dot org  2004-07-05 19:01 -------
either i screwed something up or this is a gentoo specific problem i guess.
sorry about that, marking invalid.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[mg_gentoo at yahoo dot com]

------- Additional Comments From mg_gentoo at yahoo dot com  2004-07-23 03:29 -------
No, this is a bug in GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT, it does not respect the
GCC_NO_EXECUTABLES at all.  I ran into the problem building a cross compiler (on
gentoo/amd64, but it is not a gentoo-specific problem).  When configuring in
libstdc++-v3, the host and target are i386-mingw32msvc and the build is
x86_64-pc-linux-gnu.  Obviously we cant be testing executables on a foreign host.

I have worked around it by wrapping up the innards of
GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT, but this is not a real fix.  Real fix would
be to make it respect the xcompilation situation just like probably happens a
hundred other places in the build system.  Have not tracked this fix down yet
myself though.

ccing Daniel, I think he might be able to help with fixing.

/me would reopen if could, but up to lv/unassigned


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dan at debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[mg_gentoo at yahoo dot com]

------- Additional Comments From mg_gentoo at yahoo dot com  2004-07-23 08:58 -------
Oh, a note, the problem I encountered was first triggered at the main in -lm
check in aforementioned GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT.  lv's report is
elsewhere.  Sorry about that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 fails to configure on amd64 with multilib enabled

[lv at gentoo dot org]

------- Additional Comments From lv at gentoo dot org  2004-07-23 09:18 -------
re-opening...? 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 - GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT does not respect GCC_NO_EXECUTABLES

[lv at gentoo dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|gcc 3.4.1 fails to configure|gcc 3.4.1 -
                   |on amd64 with multilib      |GLIBCXX_CHECK_COMPLEX_MATH_S
                   |enabled                     |UPPORT does not respect
                   |                            |GCC_NO_EXECUTABLES


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] gcc 3.4.1 - GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT does not respect GCC_NO_EXECUTABLES

[mg_gentoo at yahoo dot com]

------- Additional Comments From mg_gentoo at yahoo dot com  2004-07-23 11:07 -------
Thought I'd add more detailed notes, after having conversed a bit with lv:
Same problem occurs later on after working around (disabling and defaulting) for
math, in the wchar_t check, and much later, for strerror, and so on.
However, I'm not so sure as to where exactly the problem is any more. 
GCC_NO_EXECUTABLES is called for cross compilation way up around line 45 of
configure.ac.  So basically all the non-xcsafe-wrapped tests (like math, complex
math, wchar_t, etc) that come after would appear to me obviously doomed.  Mind
you I could easily be missing something (which is why I cced Dan).

Further, my problem might be separate from lv's.  He shouldn't, afaict (again, I
might be wrong), be being flagged as cross compiling, unless perhaps it's
multilib related.

BTW, is there a particular reason that mingw does not do the hardwired
AC_DEFINES in crossconfig.m4 like so many other hosts, but rather the actual
checks?  That part of the workaround, judging by the surrounding entries, looks
like it may be actually valid (that, or just a generally accepted hack for lack
of anything better).

Dunno...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] Fails to build the target libstdc++-v3 library on a cross to any linux

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|x86_64-pc-linux-gnu         |
   GCC host triplet|x86_64-pc-linux-gnu         |
 GCC target triplet|x86_64-pc-linux-gnu         |*-linux-gnu
           Keywords|                            |build
            Summary|gcc 3.4.1 -                 |[3.4/3.5 Regression] Fails
                   |GLIBCXX_CHECK_COMPLEX_MATH_S|to build the target
                   |UPPORT does not respect     |libstdc++-v3 library on a
                   |GCC_NO_EXECUTABLES          |cross to any linux
   Target Milestone|---                         |3.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] Fails to build the target libstdc++-v3 library on a cross to any linux

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-26 14:17 -------
*** Bug 16710 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |remedy at programmit dot co
                   |                            |dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] Fails to build the target libstdc++-v3 library on a cross to any linux

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |16651
              nThis|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] Fails to build the target libstdc++-v3 library on a cross to any linux

[mg_gentoo at yahoo dot com]

------- Additional Comments From mg_gentoo at yahoo dot com  2004-07-26 23:06 -------
Pointing out a couple more things that may or may not be obvious (and hey, I
don't mind making this bug show up in peoples' mailbox some more d=):

1) Bug 16710 (the dup) is cross compiling like me, only not to mingw but rather
to powerpc linux (iirc).  It is also choking in the complex math support check.

2) lv's (I thought I'd mentioned this but apparently it was to lv and not on the
bug) failure is (iirc) the sin check in lm which is from the MATH_SUPPORT (not
complex) check, which is because he is NOT cross compiling, which is correctly
identified, and thus he gets sent into the GLIBCXX_IS_NATIVE block (unlike the
other guy and I).  I believe his bug is that GCC_NO_EXECUTABLES should not be
being set (but possibly is due to multilib?  just speculating), OR it is
correctly set somewhere (again I speculate multilib, but dunno), but the same
form of detection is NOT used in that is_native block or in that macro or
somewhere else.  See also OT block marked off below.

3) The xc checks (see crossconfig.m4) look to me destined to fail...but mingw is
not the only one that uses them (although it is the only entry so devoid of
other defines and hardwires).  So I naively thought, "I must be missing
something, it looks like anybody cross compiling for any of these wchar/cplxmath
support checking platforms would immediately and surely run right into the exact
same problem".  Now, it occurs to me, "I must be missing something, perhaps in
the case of libstdc++-v3 where we set the host equal to the target, rather than
using the build (because it is a lib, not a tool) it is our usage/inheritance of
GCC_NO_EXECUTABLES which is incorrect, in that we do indeed want to try
linking?"  We can run the bloody build platform hosted cross linker if we arent
canadianing, it is still hosted on our build platform (binutils, and for that
matter all the prior parts of gcc, are build == host).  We just cannot do
anything on the (*86*, for example) build platform with the foreign (ppc/mingw,
for example) target-platform hosted library.  Am I making any sense?  I feel
like I may be understanding the situation, just not the build var wizardry to
manipulate in gcc's system to fix it.

--
OT: Anyway, I'm still wondering if my bug and 16710 are actually independent of
lv's bug as originally filed (as explained a couple times before, with him
having build == host == target, there isnt any reason for gcc_no_executables,
unless it is some misinherited facet of multilib that I dont understand).
--

4) Partially OT: libm is part of glibc....  Is this check for complex math
support supposed to be about the build compiler (my glibc-having linux
installation) or the cross compiler (also running on linux and being able to use
my glibc) or the target (which, while it could have glibc if I built it (which
of course would require a compiler for that target), does not have it)?  IOW, is
it intended to use the cross linker to check whether or not it can link target
executables/libs against libm, or is it intended to use the build linker to
check whether or not it can link the cross compiler against libm?  I think this
may be relevant.  I guess, if there is a discrepancy btwn what it should be
trying to do and what the check as currently written is actually trying to do,
or btwn what it is actually trying to do and the macro (and hence, linker (build
or cross)) with which it is trying to do it.


I hope someone besides me can actually understand me (-:

Are there any other individuals from gcc that we can cc to get some better
insight?  I feel like I'm getting nowhere by all this speculation, and probably
making a fool of myself to anyone who does actually know what is and isnt going
on in the build system code.

BTW, thanks for the qa work, Andrew.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] Fails to build the target libstdc++-v3 library on a cross to any linux

[lars dot sonchocky-helldorf at hamburg dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lars dot sonchocky-helldorf
                   |                            |at hamburg dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] Fails to build the target libstdc++-v3 library on a cross to any linux

[remedy at programmit dot co dot uk]

------- Additional Comments From remedy at programmit dot co dot uk  2004-07-27 07:23 -------
Its rather fabulous that all of us understand that it actually DOES crash 
there and won't go any further without magic tweaking :) I wish i could fix 
myself that and just keep going, but since i cannot i am here guys wondering 
if anyone has got any idea how to tackle that :( 
 
Any ideas? 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] Fails to build the target libstdc++-v3 library on a cross to any linux

[mg_gentoo at yahoo dot com]

------- Additional Comments From mg_gentoo at yahoo dot com  2004-07-29 16:39 -------
Well I figure we can just keep replying to ourselves until someone who knows how
to fix it gets fed up with all the mail (-:  *ducks*


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] Fails to build the target libstdc++-v3 library on a cross to any linux

[abiggadike at yahoo dot com]

------- Additional Comments From abiggadike at yahoo dot com  2004-08-24 19:09 -------
Trying to build a cross compiler for Solaris 9 x86 and I'm seeing the same
problem when building binutils (which contains libiberty).

Configure:
../binutils-2.15/configure --host=i686-pc-linux-gnu --target i386-pc-solaris2.9  \
                --with-headers=/path/to/headers --with-libs=/path/to/libs \
                --prefix=/path/to/prefix -v --disable-nls

Error occurs during 'make':
Configuring in libiberty
/solaris-9/build-binutils/libiberty
configure: loading cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo
checking for perl... perl
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for i686-pc-linux-gnu-ar... ar
checking for i686-pc-linux-gnu-ranlib... ranlib
checking for i686-pc-linux-gnu-gcc... gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking whether gcc and cc understand -c and -o together... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking whether byte ordering is bigendian... no
checking for a BSD-compatible install... /usr/bin/install -c
xhost-mkfrag is unchanged
checking for sys/file.h... yes
checking for sys/param.h... yes
checking for limits.h... yes
checking for stdlib.h... yes
checking for malloc.h... yes
checking for string.h... yes
checking for unistd.h... yes
checking for strings.h... yes
checking for sys/time.h... yes
checking for time.h... yes
checking for sys/resource.h... yes
checking for sys/stat.h... yes
checking for sys/mman.h... yes
checking for fcntl.h... yes
checking for alloca.h... yes
checking for sys/pstat.h... no
checking for sys/sysmp.h... no
checking for sys/sysinfo.h... yes
checking for machine/hal_sysinfo.h... no
checking for sys/table.h... no
checking for sys/sysctl.h... yes
checking for sys/systemcfg.h... no
checking for sys/wait.h that is POSIX.1 compatible... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether errno must be declared... no
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... yes
checking for strings.h... (cached) yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... (cached) yes
checking for uintptr_t... yes
checking for pid_t... yes
checking for library containing strerror... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make: *** [configure-libiberty] Error 1




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] libstdc++ fails for crosses

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-25 04:16 -------
I can confirm this with a cross to i686-pc-darwin (yes that is hard to get a cross going but ..)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-25 04:16:14
               date|                            |
            Summary|[3.4/3.5 Regression] Fails  |[3.4/3.5 Regression]
                   |to build the target         |libstdc++ fails for crosses
                   |libstdc++-v3 library on a   |
                   |cross to any linux          |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] libstdc++ fails for crosses

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-25 04:16 -------
*** Bug 16651 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/3.5 Regression] libstdc++ fails for crosses

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-29 18:55 -------
Postponed until GCC 3.4.3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.2                       |3.4.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses

[nospam-bugzilla at uun dot org]

------- Additional Comments From nospam-bugzilla at uun dot org  2004-09-15 02:42 -------
Note that I seem to get this same bug when trying to compile gcc-3.4.2
*natievly* on OpenBSD 3.5.  This is without any kind of cross-compilation
environment.  I just unpack gcc-core-3.4.2.tar.bz2 and gcc-g++-3.4.2.tar.bz2.

I even tried configuring like this:
 
./configure --prefix=/usr/local/gcc3 --build=i386-unknown-openbsd3.5
--target=i386-unknown-openbsd3.5 --host=i386-unknown-openbsd3.5 --disable-multilib

And note I'm also building with GNU make, but the build still stops with the
same error.  This seems to be happening because the configure script can't link
a simple program--it uses a symbol called _atexit, while libc.a uses the name
atexit.  Therefore it decides it must be cross compiling.  Perhaps this is
caused by a different bug stemming from OpenBSD's switch to ELF on the i386?






-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses

[jtison at ntplx dot net]

------- Additional Comments From jtison at ntplx dot net  2004-09-28 13:42 -------
> checking for sin in -lm... configure: error: Link tests are not allowed after
> GCC_NO_EXECUTABLES.

Thanks for the extensive commentary & remarks on this bug. I've been wrestling
with this behavior since the 3.x branch began, and I've been quietly lurking,
benefiting from everyone else's remarks, opinions, etc. Perhaps just tracking
the observed changes in behavior might give someone a clue on how to best
address them at some time in the future. <beg mode>Soon, please??</beg mode> 

I used to be able to get by with some brute-force hacks to libtool sources in
the libstdc++-v3 source tree, all with the end result of getting a libstdc++.so
built for my pet cross-target-only CSN. Now I'm stuck again on the subject bug,
just like everyone else, until I figure out the _next_ piece of magic hackery. 

Some observations (based on a 2004.09.26 snapshot of savannah HEAD, opinions are
mine and not intended to start a flame fest): 

1. If GCC_NO_EXECUTABLES gets called, and $gcc_no_link thus gets set to 'yes',
you're toast, even should the configure phase finish without error (rare). "make
install" will fail to install any .so libs at all, despite the fact that all
other (known, supposed) conditions are met for a righteous .so build. Static C++
libraries just aren't expected, and they aren't acceptable substitutes for a
real dynlink library. Is libtool really the right tool to use in this case? Or
am I losing sight of the embedded OS' needs?

2. Sometimes GCC_NO_EXECUTABLES (really, $gcc_no_link) gets set in error. I ran
into this one again last night: for some reason I can't grasp, a -V with no arg
made its way onto the gcc command line, which is a cmdline switch usage error.
This specific gcc call was happening (probably, see 4.a, below) in the
AC_PROG_C* call early on, and resulted in $gcc_no_link = 'yes'. When I
brute-force hacked the -V args out (4 places), the first configure/libtool phase
($build=build) managed to work. Now I just bump into the subject error.

	2.a) To debug these kinds of errors, you _have_ to go back to config.log in
your build tree. From there, you should get a clue what the _actual_ error was.
Sometimes it's not the error reported at stdout. 

	2.b) Older libtool invocations call ltconfigure, which reports itself
as 'configure', too -- both at stdout and in the log. The 'configure:' line
number in config.log just might not be from the configure script you think --
whenever libtool's involved, you **have to** take this into account.   

3. libstdc++/configure.ac has a telling remark in it: "You will slowly go insane
if you do not grok the following...". It then explains that libtool gets called
_twice_ in this configuration: once with $build set to --build && $host set to
--host; and then again with $build set to --host and $host set to --target.
These two calls -- in theory -- properly set libtool up for a cross-compilation.
Sorta makes sense, I guess, if you really _have_ to use libtool. 

But this presents a few problems. For example, if I know something non-standard
about the --target=CSN support, how do I get exception code patched in for the
context of the second ($host=$target) call without breaking the context of the
first? Was libtool (or autoconf, for that matter) _really_ designed to work like
this? I can't believe it was. 

	3.a) Was it the maintainers' intent to suppress libstdc++.so generation
for any and all cross-compiles? The presence of a call to GCC_NO_EXECUTABLES
right after that comment in configure.ac (in the case where $build != $host)
makes me wonder.

4. gcc in general is terribly back-level with respect to the auto{make,conf} &
libtool tools used to configure its build, and there seem to be impedance
mismatches between versions of the same tool depending on the subtree in which
you find yourself. 

If I have to suggest a mod to one of these tools' inputs to get a desired
downstream result, which levels of all these tools do I need to have? I've
looked, and I don't see any advice on this subject. 

	4.a) If you have to debug what auto* actually DID at any point, you
_must_ have the _exact_ same .m4 libraries that the person who regenerated the
tool script did. Otherwise, you might never prove the link between cause and
symptom.

	4.b) <ducking> Would it be possible to grab one each source tree of
autoconf, automake, and libtool; then freeze them and distribute their sources
along with gcc so that everybody's on the same tooling page? I know there are
tons of reasons why we'd want to avoid this; but does the out-of-sync chaos
outweigh the reasons contra? 

5. ac/am/libtool have all recently been on a migration phase that autoconf seems
to have started right around ac 2.13 dealing with the semantics of --build,
--host, and --target; which can have subtle but dramatic effects on
cross-builds. From all I can tell, the subject tooling all seems to be on the
same page now wrt semantics. Does the maintainers' understanding of
build/host/target match up with what _these_ specific combinations of
auto*/libtool think they mean? Appears so at first glance, but what about the
generated code itself? We're seeing some really bizarre behaviors in the config
step to this build -- libstdc++-v3/configure is now up to 91,100+ lines ... far
too much for any single person to analyze with the proper attention to detail.
I'd love to claim that configure.ac is all that has to be analyzed; but I think
I've already presented reasons why that won't work.

	5.a) Is it on anyone's radar screen to get all gcc-embedded uses of
auto*/libtool caught up to date? 

	5.b) I'd volunteer to do it in this case, except that I don't grok the
detail-level _goals_ of configuration given its complexity level. Is there any
one person out there with this knowledge? Even if the rest of gcc isn't
addressed, we need to address this _specific_ problem as it relates to libstdc++
real soon now. This part of the build appears to be broken for certain target
CSNs -- don't ask me for proof, but I'm convinced the fault is right here.

Maybe this is due to _my_ error in the (probably) naive way I've set up the
target CSN in libtool. But then again, there shouldn't be any requirement for
full target runtime functional support in order to get an .so generated: this
works for every other similar lib I've built in this tree ... why not libstdc++?

Thanks for listening to me rant. My apologies for the length. This bug is
_really_ frustrating. Any and all suggestions gratefully accepted, on- or off-list.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-11-01 00:46 -------
Postponed until GCC 3.4.4.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.3                       |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses

[mg_gentoo at yahoo dot com]

------- Additional Comments From mg_gentoo at yahoo dot com  2004-11-10 21:11 -------
Jim, you expressed an interest in this bug a while back, suggesting 1) using
sysroot - which I tried, it didn't help anything and 2) looking for an
unspecified something in config.log.
Can you provide any insight?  Tell us what to look for perhaps?  I'll do just
about anything to bring about a clean fix.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at specifixinc dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses

[wilson at specifixinc dot com]

------- Additional Comments From wilson at specifixinc dot com  2004-11-11 00:40 -------
Subject: Re:  [3.4/4.0 Regression] libstdc++ fails for
	crosses

On Wed, 2004-11-10 at 13:11, mg_gentoo at yahoo dot com wrote:
> ------- Additional Comments From mg_gentoo at yahoo dot com  2004-11-10 21:11 -------
> Jim, you expressed an interest in this bug a while back

Maybe on the gcc list?  I don't recall this PR, and don't see any
comments from me in the the PR.

I think the key detail here is that you have to have a target C library
before you can build a target libstdc++.  Of course, if you are
bootstrapping a build environment, then you need the target gcc before
you can build the target C library.  This gets tricky when glibc is
involved.  You need to first install the glibc headers so you can build
libgcc.  Then you do a partial gcc build.  You build only the compiler
and libgcc without the libraries like libstdc++.  Then you use gcc to
build a provisional glibc.  Then you can build a full gcc including
libstdc++.  Then you build a full glibc.  Then See Dan Kegel's crosstool
that automatically does this for you.
    http://kegel.com/crosstool/

If you don't want to go through all of the trouble of bootstrapping an
entire build environment, there is a much simpler way to do this.  Use a
sys-root.  The sys-root must include header files and libraries for the
target.  Gcc will then be able to find them, and link tests will work,
and libstdc++ will configure OK.  If libstdc++ won't configure, then
something is missing from your sys-root.

There is another way to solve this problem which is to hand-code in
answers to all of the questions that the libstdc++ configure script
asks.  This is what crossconfig.m4 tries to do.  However, I doubt that
this is kept up to date.  Every time the configure script changes, the
answers in crossconfig.m4 need to change to keep up to date.  For most
targets, no one bothers to do that, and hence this is likely always out
of date.  Since there are other better ways to get a cross compiler
built, this is probably not worth the trouble.  One of the problems with
providing hand-coded answers is that the answers can be wrong if someone
has a system with non-standard packages on it.  So this is usually a
solution of last resort.  It may be worthwhile for some targets though. 
Note that we use this same trick in libiberty, but there we don't have a
choice because libiberty has to be buildable without a C library.  This
is must simpler to do though, as there are fewer questions asked by the
libiberty configure script, and the list of questions rarely changes,
and the answers to those questions also rarely change.

I would guess that the gentoo configure problem is because the host OS
does not have a multilibbed C library.  If the x86_64 gentoo system does
not have both the 32-bit and 64-bit C libraries in /lib, then one of the
multilibbed libstdc++ builds will fail to link, and you end up with the
same "cross-compiler" problem.  This has to be fixed as above, e.g. you
must provide a multilibbed glibc before you can do a multilibbed gcc
build, or else you have to build gcc/glibc together as per Dan Kegel's
crosstool.

Incidentally, the error message referring to GCC_NO_EXECUTABLES is a
misnomer.  This gets printed if gcc_no_link is true, and
GCC_NO_EXECUTABLES does set gcc_no_link.  However, gcc_no_link also gets
set by AC_PROG_CC which is the standard autoconf test for determining
whether the C compiler works.  If autoconf determines that the C
compiler can not link, then it sets gcc_no_link.  This explains why a
native build can see this "cross-compiler" problem.  AC_PROG_CC fails to
link if there is something missing from your compiler environment, which
as I explained above, is most likely a missing C library.

I am not convinced that there is any bug here.  I think the only problem
is people not understanding how to do cross compiler builds, which can
be much more complicated than native builds.  My company has recently
done cross compiler builds for linux from gcc-3.4 and we didn't have any
problem.  Many inexperienced gcc developers have been able to build
linux cross compilers by using Dan Kegel's scripts.  Hence I don't
believe there is any real bug here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses

[mg_gentoo at yahoo dot com]

------- Additional Comments From mg_gentoo at yahoo dot com  2004-11-11 03:45 -------
Well, the problem isn't inexperience (in my case anyway) so much as that a
process which worked in the past does no longer since the introduction of
certain new build magic (for the better, mind you) in 3.4.
Since, I suppose, the process must adhere to stricter borders these days, I'll
be more than happy to work through it from scratch (probably tomorrow or friday)
to see where my existing environment and scripts have failed.
Thank you for the input.  I knew if I kept ccing more and more people that had
something to do with this (albeit the better part of a year ago), I'd eventually
find someone awake.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] libstdc++ fails for crosses

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-05 03:14 -------
Actually I found out a couple of days ago this just means you it cannot find the library and not a 
configure failure.
For the orginal reporter, do you have a full glibc and the 32bit glibc  if you don't then you have to 
disable the multilib (aka --disable-multilib).

For all the rest of the reports are you sure that you have the libraries installed?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
            Summary|[3.4/4.0 Regression]        |libstdc++ fails for crosses
                   |libstdc++ fails for crosses |
   Target Milestone|3.4.4                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371

[Bug libstdc++/16371] libstdc++ fails for crosses

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-06 15:40 -------
No feedback in 3 months.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371