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

["jtison at ntplx dot net" <gcc-bugzilla at gcc dot gnu dot org>]

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