Why does libiberty have to build before a C library?

[Daniel Jacobowitz <drow at mvista dot com>]

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.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer