Re: Why does libiberty have to build before a C library?

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Jun 10, 2003 at 12:02:56AM -0600, Tom Tromey wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> >> # 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.
> 
> Daniel> The interesting question is, why do we need this at all?
> 
> My recollection, from way back when, was that the compiler couldn't
> link at the time this macro was executed.  I'm pretty sure this didn't
> have to do with library ordering, since when this code went in (for
> libjava, the original code was written in 1998, and goes back to
> before the public CVS) libjava worked with a newlib-based target but
> we still needed the macro change.
> 
> Maybe it was as Geoff says: the target needed special flags in order
> to link at all.  In our case it was a MIPS target, not PPC, but
> perhaps the same thing holds.
> 
> However, what I remember is that we ran all the target configure
> scripts before building any of the target libraries.  In this
> situation, build order wouldn't matter since newlib would only be
> configured, not built, at the time when AC_PROG_CC is invoked -- so no
> C library would be available at all.

Huh - well, this prompted me to look at gcc 3.2's config scripts, and I
learned two things:
 - In 3.2, libjava depended on ALL_GCC_C, so newlib would have been
   available.  In 3.0 it depended on ALL_GCC_CXX, which should also
   have done the trick.  In 2.95 it depended on ALL_GCC, so that might
   explain the problem.  Alex fixed this in 2000.

 - In 3.2, libiberty depended on ALL_GCC_C; that lasted until:

2003-05-21  DJ Delorie  <dj@redhat.com>
        
        * Makefile.tpl (configure-target-libiberty): Depend only on gcc, not
        newlib or libgloss.
        * Makefile.in: Regenerate.

DJ, that's pretty recent - could you explain why it was done?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer