How did these testresults get generated then: <http://gcc.gnu.org/ml/gcc-testresults/2004-07/
msg00070.html>?

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.

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.

Indeed, today I also built 3.4.1 on x86_64 (multilib by default), no problem...

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.

either i screwed something up or this is a gentoo specific problem i guess.
sorry about that, marking invalid.

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

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.

re-opening...? 
 

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...

*** Bug 16710 has been marked as a duplicate of this bug. ***

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.

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? 

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*

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

I can confirm this with a cross to i686-pc-darwin (yes that is hard to get a cross going but ..)

*** Bug 16651 has been marked as a duplicate of this bug. ***

Postponed until GCC 3.4.3.

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?

> 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.

Postponed until GCC 3.4.4.

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.

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.

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.

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?

No feedback in 3 months.

(sorry to comment on something so ancient).  Anyway ran into something similar today, a couple of hints/clues: mine was caused by having an empty environment variable CFLAGS (like bash's export CFLAGS=).  So unsetting that and I was good to go.
Also (as others have noted) this error message basically means "your cross compiler is unable to link at all" or something like that (the config.log that may describe it is called something like i686-w64-mingw32/libstdc++-v3/config.log)