This is the mail archive of the
mailing list for the GCC project.
Re: [RFA:] (PR fortran/21184) config-lang.in: target_libs spawn
- From: DJ Delorie <dj at redhat dot com>
- To: hans-peter dot nilsson at axis dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 6 Jun 2005 17:01:58 -0400
- Subject: Re: [RFA:] (PR fortran/21184) config-lang.in: target_libs spawn
- References: <200506061949.j56JnRW8015837@ignucius.se.axis.com>
> Well, perhaps that too, but the target *library* is usually where
> porting activity goes, not the language front-end.
Having ported gcc to many chips, I disagree. The compiler backend and
libgloss are the places where most of the porting happens. I don't
think I've ever had to "port" libstdc++.
> > I don't think we should infer it based on which libraries happen
> > to work.
> Why not? That's how things usually work in this tree.
Because we can't imagine the reasons why a target library would be
unsupported, or what the user is planning on doing with the compiler.
We have targets that don't support *libiberty* but that doesn't mean
we shouldn't build a C compiler.
*If* we had a more reliable way of saying what parts of what target
libraries are *required* for a compiler to work at all (libgcc for C,
libsupc++ for C++) and which parts we can do without (libstdc++ for
C++) I'd feel more comfortable with it. But as you pointed out,
Cygwin is already using the macros wrong, so my confidence that your
plan will work reliably is already low.
> That's developer talk, and definitely not the common case.
Of course, since I'm a developer.
> For your needs, --enable-languages=c++ should override the target
> library presence decision, perhaps letting a target enable as well
> as disable.
Hmmm... that's probably a valid requirement anyway.
> > Now, if a target *can't* build a working language compiler, that's a
> > different story.
> No, a "working language compiler" requires working libraries.
> Same story.
But we already support vendor-supplied runtime libraries.
> Having said that, I see a hard route trying to convince you and
> little time doing that, so I'll try getting through with
> target-overridability of languages.
I think that's the right way to go. While it would be nice to have
the dependencies "just work automatically", I imagine that this is
more of a can of worms than an elegant solution.
Plus, I don't think coding for the "common case" is good enough,
especially when I'm not in it.