Re: change target libs to not try to link stuff

[Geoff Keating <geoffk at cygnus dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Aug  3, 2000, Geoff Keating <geoffk@cygnus.com> 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.  You also need to know _which_ libgloss board
support is to be used, which is something that you can't tell at this
point.  I'm told that on mips, you have to specify a -T option on the
command line to say which board is to be used, otherwise the link will
simply fail, which is the preferred behaviour from the user's point of
view but not good for autoconf.

> BTW, this macro LIB_AC_PROG_CC doesn't work with CVS autoconf.  It
> uses some internal macros of autoconf, that have been renamed.  We'd
> better adapt.  I'm pushing for some autoconf macro that allows
> configure.in to declare it's configuring part of a toolchain
> bootstrap, so it should skip the compiler test.

Yes.  autoconf should be fixed.  There are other severe problems with
autoconf in CVS and so I don't think there's any reasonable chance of
using 2.50 for gcc reliably, so I believe that it'd be better to have
autoconf fixed and then we can move to the fixed version.

In fact, the macro I used is copied from libiberty/configure.in and
so if there are problems with it then there are already problems
elsewhere and the best thing is to fix them together when the fixed
version of autoconf comes out.

> Before we have that, it should be enough to add to configure.in,
> before AC_PROG_CC, the following snippet:
> 
> AC_DEFUN([AC_PROG_CC_WORKS],) dnl for autoconf 2.13
> AC_DEFUN([_AC_PROG_CC_WORKS],) dnl for autoconf 2.50

There's also the AC_EXEEXT issue.  However, this seems much cleaner;
I'll try it.

> But this should only be necessary for newlib and libgloss.  All other
> target libraries' configure should already depend on these libraries
> being having been built.  libstdc++ will probably benefit from a
> similar hack for [_]AC_PROG_CXX_WORKS.

libstdc++ doesn't use autoconf.  It's still Cygnus configure, I believe.

It's not a coincidence that the C and C++ libraries didn't need
fixing.  Cygnus only supports C and C++ and Java, and so it makes them
work in a cross environment.  It doesn't support (yet) F77 and ObjC,
so those libraries were broken.

Again, you are repeating the arguments that were made last time.  I'm
not interested in repeating such a debate.  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.
-- 
- Geoffrey Keating <geoffk@cygnus.com>