Re: [PATCH] Some inconsistency in collect2, with respect to gcc and libtool

[Ossama Othman <ossama at ece dot uci dot edu>]

Hi,

On Mon, Jul 10, 2000 at 05:19:47PM +0200, Marc Espie wrote:
> Collect2 has some code to parse arguments which is less than perfect,
> especially when one takes libtool into account.
> 
> Specifically, gcc specs documentation explicitly says that any file that does
> not have default rules will be transparently passed to the linker.
> 
> On the other hand, collect2's parser does only recognize .o files as proper
> object files.
> 
> What this means is that libtool CAN'T support .lo on any platform that relies
> on collect2 to do its job. 
> 
> This is especially important for C++, where g++ -shared might be the only
> sane way to ensure constructors are going to be called.
> 
> So, I'm wondering about how to fix that. A simple fix would be tell collect2
> that .lo are also object files. Here it is:
> 
> Mon Jul 10 17:10:09 MET DST 2000		Marc Espie <espie@openbsd.org>
> 	* collect2.c (main):  Recognize .lo as object files.

From libtool's point of view, this patch won't be necessary after libtool
1.5 is released.  Libtool's multi-language branch (which libtool 1.5 will
be based on) no longer creates object files that end with `.lo'.  Instead,
`.lo' files are analogous to the `.la' files used for libraries created
by libtool.  Specifically, libtool 1.5 will only pass object files that
end with `.o' (or whatever the detected object file extension is) to the
compiler/linker.  The `.lo' files contain information about where PIC and
non-PIC object files reside.

This change was necessary to properly support compilers that support C++
template repositories, for example.

-Ossama
-- 
Ossama Othman <ossama@ece.uci.edu>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068  70E6 5EB7 5E71 F7A3 94A8