change target libs to not try to link stuff

Geoff Keating
Thu Aug 3 17:56:00 GMT 2000

> Cc:
> From: Alexandre Oliva <>
> Organization: GCC Team, Red Hat
> Date: 03 Aug 2000 18:21:10 -0300
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Carlsbad Caverns)
> On Aug  3, 2000, Geoff Keating <> wrote:
> > Alexandre Oliva <> writes:
> >> On Aug  3, 2000, Geoff Keating <> wrote:
> >> 
> >> > While the target libs are being built, you can't try to link programs,
> >> > as (a) not all the required files are done yet
> >> 
> >> I've recently installed a patch in the top-level Makefile that should
> >> cause the target libraries of languages other than C to be configured
> >> and built only after ALL_GCC, which includes all-target-newlib.  So
> >> this should no longer be necessary.
> > You also need libgloss.
> I thought ALL_GCC also included libgloss.

Actually, I don't see that ALL_GCC includes anything other than the
compiler itself.  It can't include newlib, because newlib depends on

configure-target-newlib: $(ALL_GCC)

> > You also need to know _which_ libgloss board support is to be used,
> > which is something that you can't tell at this point.
> Why not?  I'd hope this could be handled by the top-level
> FLAGS_FOR_TARGET stuff, even if this means adding some extra configure
> option or target names to determine the -T option in the mips
> platforms you mention.

You misunderstand.  The target mips-unknown-elf supports multiple
boards.  There is no default.  There is no 'right choice'.

We don't want to have separate configurations for each target board.
There's no reason to do this, it's far too expensive to test and
support, and it's annoying for users.

> > There's also the AC_EXEEXT issue.
> I don't think it's an issue.  By the time we configure libobjc, we
> should already have all the pieces in place to be able to build C
> executables, except for the weird mips case you mentioned, which I'd
> rather work around some other way.  Disabling AC_EXEEXT is precisely
> the wrong thing to do, IMO.

Again, you misunderstand.  There's no reason why you can expect to
_ever_ be able to build C executables for some targets.

Consider vxworks, for instance.  There is no 'executable'.  They link
everything with -r into a .o file which gets downloaded to the board,
and then linked again against the OS running on the board.

So what does AC_EXEEXT mean for such a target?  It's meaningless.
The final executable doesn't even have a name.

Or consider building an x86-linux to powerpc-aix toolchain.  I can't
link anything because the linker isn't written yet.  But why can't I
make a cross-toolchain that includes everything else, and perform the
final link on a real AIX box using the system linker?

> > libstdc++ doesn't use autoconf.  It's still Cygnus configure, I believe.
> True, but libstdc++ is pretty much dead (i.e., no longer under
> development).  libstdc++-v3 uses not only autoconf, but also automake
> and libtool.

Well, it too will need to be fixed.

> > Again, you are repeating the arguments that were made last time.  I'm
> > not interested in repeating such a debate.
> I don't recall that debate, sorry.  Would you mind pointing me at the
> mailing list and time frame on which they took place?
> > Since the target libraries never link anything in an embedded
> > environment without shared libraries, I don't see that it's relevant
> > whether or not the linker (a) works, (b) exists, or (c) how it
> > behaves.
> Cross environments with shared libraries are becoming more and more
> common these days.  By simply disabling certain tests, we'd just
> making their lives more difficult.  Instead, we should arrange for the
> tests to work whenever it makes sense.

So, what should AC_EXEEXT do in an environment where it's impossible
to link executables?  What should AC_PROG_CC_WORKS do?  What does it
mean to ask whether CC 'works' in the context of building a library?

I wouldn't mind so much if AC_EXEEXT just ran its test and produced
some random result, or a warning message.  Instead it blocks building
the library involved.
- Geoffrey Keating <>

More information about the Gcc-patches mailing list