This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA:] (PR fortran/21184) config-lang.in: target_libs spawn


> Date: Mon, 6 Jun 2005 14:50:17 -0400
> From: DJ Delorie <dj@redhat.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
> available.

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

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.

brgds, H-P


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]