This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Why is libiberty built for the target? (was Re: Why does libibertyhave to build before a C library?)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Cc: dj at redhat dot com, geoffk at apple dot com
- Date: Mon, 09 Jun 2003 21:47:16 -0700
- Subject: Why is libiberty built for the target? (was Re: Why does libibertyhave to build before a C library?)
- References: <20030610040442.GA26729@nevyn.them.org>
Daniel Jacobowitz <drow@mvista.com> writes:
> 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?
I'd like to ask a deeper question: Why is libiberty built for the
target? I am not aware of any use whatsoever of the generated
libiberty.a. Certain libraries want to suck in the C++ demangler but
they can do it the same way gcc and binutils do, viz. by building an
.o from the libiberty source.
Daniel's question is still relevant in the context of language
runtimes (libstdc++, libjava) of course.
zw