This is the mail archive of the 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: Criteria for GCC 4.0

> -----Original Message-----
> From: gcc-owner On Behalf Of Richard Kenner
> Sent: 01 June 2004 13:43

>     How do _you_ propose to teach the driver that in such 
> multilanguage
>     projects, say Ada/C++, it must link both the language's runtime
>     libraries?  Are you suggesting that my some machical 
> means it should
>     derive that from the object files, or just via user 
> flags?  You could
>     do the latter just as well by using gnat and add -lstdc++ to the
>     linker options.
> I don't have any specific proposals, but this certainly is 
> something that
> must be done somehow if GCC is to succeed with modern large projects.
>     So I don't see how the driver knowing about libraries 
> would make things
>     easier to do multi-language linking support.
> Suppose I have a project that's using both Java and C++.  If 
> I had just Java,
> I'd call one driver program and if I had just C++, I'd be 
> calling another.
> With both, which do I call?  That confusion is not helpful.

  Maybe a good solution to this problem would be to give the
language-specific drivers an option to do a not-quite-final link, i.e. to
link a bunch of objects together with the relevant language-specific
library(ies) but whilst passing the "-r" flag to ld.  Then there could be a
second option to do a final-final link which purely accepts the objects and
libs supplied by the user on the command line, adding no language-dependent
libs at all, but this time without the -r flag to generate the final exe ?

Can't think of a witty .sigline today....

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