This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why does libiberty have to build before a C library?
On Mon, Jun 09, 2003 at 09:28:40PM -0700, Geoffrey Keating wrote:
>
> 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.
Hmm, I was hoping that none of them did. I'll check.
> >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.
But we need to be able to build target libraries, without the user
providing us with these libraries via LDFLAGS_FOR_TARGET or similar?
That seems pretty bogus. It seems to me that we should be able to
build a C compiler and libgcc without this information, but not
libstdc++.
I'll build a powerpc-eabi toolchain tomorrow and poke around at it;
it's been a while.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer