Why does libiberty have to build before a C library?

[Geoffrey Keating]

On Monday, June 9, 2003, at 09:04  PM, Daniel Jacobowitz wrote:

> A lot of the autoconf evil in libiberty is based around this:
>
> # FIXME: We temporarily define our own version of AC_PROG_CC.  This is
> # copied from autoconf 2.12, but does not call AC_PROG_CC_WORKS.  We
> # are probably using a cross compiler, which will not be able to fully
> # link an executable.  This should really be fixed in autoconf
> # itself.
>
>
> I know how to fix it to work with 2.5x.  But that's not the 
> _interesting_
> question.  The interesting question is, why do we need this at all?
>
> There seem to be two classes of answer:
>   - So that it can be built before newlib or another C library is 
> available
>   - So that it will be able to configure even if the cross compiler 
> can't
>     link for some other reason.
>
> Well, why not arrange, when using a combined tree and a newlib target, 
> for
> libiberty to be built after newlib?  Is this even an issue?  We 
> wouldn't be
> able to build target libraries without a C library but I don't see 
> that as a
> big loss.

You would want to be sure that none of those libraries require 
libiberty.  I'm particularly thinking of cygwin here.

> For part B, I believe that it's "just" an issue of getting the target
> libraries built in the right order, and seeing that the top level 
> passes the
> right flags down.  It's tricky, but doable.
>
> I don't think we need actually to extend the AC_NO_EXECUTABLES hack for
> any of our target libraries.  We might need to use it in 
> newlib/libgloss to
> make sure that they can use AC_PROG_CC.  But they can live with the 
> static
> no-link-tests restriction; they should never be doing link tests 
> anyway.
>
> Does this make sense?
>
> [Geoff: CC'd because Alex said something about powerpc-eabi needing 
> special
> options passed around in order to link.  Any reaction to this?  They'd 
> end
> up in LDFLAGS when we configure target libraries in this scheme.]

Some targets, including powerpc-eabi, cannot link a program by default, 
because the user must provide special flags and/or libraries to specify 
initialisation, termination, and I/O code.