Language-specific libraries and `gcc' driver

[Jamie Lokier]

Theodore Papadopoulo wrote:
> Mumit also suggested directly emitting the libraries names in the 
> object file instead of identifying the compiler. I must admit that I 
> have trouble estimating the advantages and drawbacks of such a choice.
> My preference would go towards marking the language but then collect2 
> has to be aware of all languages. In the other case, each frontend is 
> responsible for naming the libraries it uses and collect2 just adds 
> these lines to the linker parameters but there will remain problems 
> of compiler versions, library versions and orders ...
> 
> Yes that would mandate that collect2 is used for all ports (but I 
> also thought that collect2 was not used with i686-pc-linux-gnu and it 
> seems to be (well it is compiled (and I think called) at least)).

Eventually, the mechanism can be added to the GNU linker.  It was done
with .gnu.linkonce.* sections after all.  When that is done, collect2
does not need to run.

Emitting the library names has the advantage that the linker can just
use those -- it doesn't need to know about languages.  However, it
doesn't make much difference if the mapping from language to library is
specifed by GCC on the linker command line.

E.g., to avoid collect2, GCC must test at build time if it's build on a
system where the linker supports the language->library feature.  In that
case, GCC can invoke the linker with `-ifdef gcc2_java_language -lgcj -endif'
or some equivalent functionality.

It might be good to emit both library and language names, for diagnostic
and tracking purposes -- as well as compiler options that affect library
compatibility since we're here.

-- Jamie