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: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: dj at redhat dot com
- Cc: hans-peter dot nilsson at axis dot com, gcc-patches at gcc dot gnu dot org
- Date: Mon, 6 Jun 2005 21:49:27 +0200
- Subject: Re: [RFA:] (PR fortran/21184) config-lang.in: target_libs spawn
> Date: Mon, 6 Jun 2005 14:50:17 -0400
> From: DJ Delorie <email@example.com>
> > To wit, the point is to stop building language front-ends where the
> > target library isn't supported, like target-libfortran for non-posix
> > targets like newlib or the java front end for any target that adds
> > $libgcj to noconfigdirs.
> No, I think what we need is a way for targets to explicitly remove
> languages from the build.
Well, perhaps that too, but the target *library* is usually
where porting activity goes, not the language front-end.
> 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.
> I usually build the C++ front end even on targets that don't support
> libstdc++ (usually due to tight memory constraints) because it's a
> useful part of the porting process.
That's developer talk, and definitely not the common case. For
your needs, --enable-languages=c++ should override the target
library presence decision, perhaps letting a target enable as
well as disable.
> I can imagine that some people
> would want to provide their own runtime libraries. I don't think we
> should arbitrarily deny them because *our* runtime libraries aren't
I can imagine adding support for such odd situations, but
keeping it simple for the usual case.
> Now, if a target *can't* build a working language compiler, that's a
> different story.
No, a "working language compiler" requires working 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.