Re: Static linked cross tools

[Jim Tison <jtison at ntplx dot net>]

On Tue, 2004-10-19 at 16:26, Allen Curtis wrote:
<snip>

> "checking for library containing strerror...configure: error: Link test 
> are not allowed after GCC_NO_EXECUTABLES."
> 
> What does this mean?

It's coming from libtool, telling you that: 
(a) some part of your (build)host-(run)host-target triad isn't fully
defined within libtool itself,
(b) the default/required linker cannot be run, or
(c) an attempt to run the default linker for either the build or host
target failed at some point. 

In many cases the link test can indeed be run; it's just that libtool
doesn't know it: either the CSN (canonical system name) of one of the
platforms isn't known, the wrong linker is specified/guessed at (or
maybe you don't even _have_ one), or maybe an attempt to run the right
linker failed for the wrong switch values. The potential causes are
numerous.

Bottom line: as libtool builds itself for a cross-compiled/cross-linked
target, its configuration script gets called once for the build host,
and then again for the run host. In other words, the first run calls
ltconfig as you'd expect: build=$build, and host=$host ... the second
run calls ltconfig with build=$host and host=$target. If, by some
happenstance, either the host or target CSN isn't fully defined to
libtool, you'll see the GCC_NO_EXEC errors. Same thing goes if the
linker for the phase can't be found/executed, or the switch settings are
bad.

My apologies for the loose treatment of the terminology involved, but
the auto* guys recently changed these definitions, and some of the auto*
-built packages haven't completely reacted yet. 

The cure for valid GCC_NO_EXEC errors is to somehow comply with the
build requirements, or make sure good linker switches are passed in
LDFLAGS.

The cure for false GCC_NO_EXEC errors is to go in and add _proper_
support for the CSN on which libtool is choking in libtool.m4, and then
have libtool regenerate everything through a clean build. At least
that's the approach with _modern_ libtool releases. You can find the
corollaries of those m4 routines -- in older libtools -- in places like
ltconfig.sh, ltcf-cxx.sh, ltcf-c.sh, and others. Many key packages
aren't using the newer libtool yet, so you'll have to feel your way
around. 

At least libtool got its act together and did (at least what I thought)
what should be done: implemented most everything affected by CSN
differences as m4 macros. 

The "run libtool twice" philosophy is employed just about everywhere for
crosses, starting with libiberty and ending with libstdc++. I could rant
about the fact that this was done (there sure is a lot of confusion),
but I understand why: if you look at it from the maintainers' point of
view, there wasn't a lot of choice.

If you're looking for an example of what you _might_ need to do to get
your favorite CSN supported (YMMV), I got a patch accepted to libtool on
2004-10-02 for s390x-ibm-tpf ... it made the libtool-1.95d release on
the following day. 

The gcc maintainers are receptive to patches to the ancient libtool
artifacts they have as long as you've submitted a comparable patch to
libtool itself.


Good luck,
--Jim--
"Smith & Wesson: The original point & click interface."


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com