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


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


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