change target libs to not try to link stuff

Alexandre Oliva aoliva@redhat.com
Thu Aug 3 14:21:00 GMT 2000


On Aug  3, 2000, Geoff Keating <geoffk@cygnus.com> wrote:

> 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.

I thought ALL_GCC also included 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.

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.

> Yes.  autoconf should be fixed.

Not all problems are in autoconf.  There are quoting problems in our
macros, and they happened to work out of luck.  We should fix those.

> There are other severe problems with autoconf in CVS

What particular problems are you talking about?  Being an autoconf
maintainer, I'd really appreciate statements a little bit more precise
than ``severe problems'' :-)

> and so I don't think there's any reasonable chance of using 2.50 for
> gcc reliably

There should be.  We might need to fix a little bit of configure.in
code here and there, that happened to work by chance, and maybe remove
some interface abuses such as the one present in all bootstrap
libraries by moving them into autoconf, but that's all.

> In fact, the macro I used is copied from libiberty/configure.in

I know.  It's in libiberty, newlib, libjava, pretty much everywhere.
And all copies will break with CVS autoconf because they use
undocumented features, that are prone to change.

I'd push for a change in autoconf so that they could keep working, but
I'd rather (i) provide some means in autoconf for us to work around
this limitation in a clean way and (ii) use these means in bootstrap
libraries' configure.ins.

> the best thing is to fix them together when the fixed version of
> autoconf comes out.

We shouldn't wait until the next version comes out.  The earlier we
attempt to get problems fixed, the better, because then people will be
able to start testing GCC with CVS autoconf before the release (not
that we should generate our CVS `configure' with CVS autoconf, but
users would have the option to rebuild `configure' with it), and we'd
have a clean work-around that (i) would built upon features of CVS
autoconf but (ii) would include a fallback for autoconf 2.13.

> 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.

> 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.

> 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.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



More information about the Gcc-patches mailing list