[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" <gcc-bugzilla at gcc dot gnu dot org>]

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