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

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

[Mike Stump]

> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 11 Jul 2000 13:15:37 -0300

> Unfortunately, even g++ won't work correctly on non-ELF systems.
> I'm talking about implicit instantiation of template static data
> members, for example.  It is my understanding that this just can't
> be done correctly on COFF, for example :-(

What is the reason that repo can't be used to make this work?

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

[Alexandre Oliva]

On Jul 11, 2000, Mike Stump <mrs@windriver.com> wrote:

>> From: Alexandre Oliva <aoliva@redhat.com>
>> Date: 11 Jul 2000 13:15:37 -0300

>> Unfortunately, even g++ won't work correctly on non-ELF systems.
>> I'm talking about implicit instantiation of template static data
>> members, for example.  It is my understanding that this just can't
>> be done correctly on COFF, for example :-(

> What is the reason that repo can't be used to make this work?

Oh, sure it can.  It just doesn't work with the default settings.
And, as you certainly know, -frepo doesn't automatically solve all the
problems, when it comes to creating libraries out of -frepo objects
(the user must try to link them into an executable first)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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

[Jeffrey A Law]

  In message < 20000710171947.A15506@liafa1.liafa.jussieu.fr >you write:
  > 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 do
  > es
  > 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 reli
  > es
  > 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 collect
  > 2
  > 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.
Installed based on Jason's approval.

jeff

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

[Alexandre Oliva]

On Jul 11, 2000, "Mark E." <snowball3@bigfoot.com> wrote:

> As of Binutils 2.10, puny ole COFF has weak symbol support so
> template static data members work just fine (when gcc is properly
> configured).

This is very good news, indeed.

Unfortunately, GNU ld doesn't support the only two platforms in which
I recall having noticed the lack of weak symbols :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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

[Mark E.]

On 11 Jul 2000 18:17:00 +0200, you wrote:

>Unfortunately, even g++ won't work correctly on non-ELF systems.  I'm
>talking about implicit instantiation of template static data members,
>for example.  It is my understanding that this just can't be done
>correctly on COFF, for example :-(

As of Binutils 2.10, puny ole COFF has weak symbol support so template static data
members work just fine (when gcc is properly configured).

Mark
-- 
Mark E.: snowball3@bigfoot.com
http://snowball.frogspace.net/

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

[Alexandre Oliva]

On Jul 10, 2000, Marc Espie <espie@quatramaran.ens.fr> wrote:

> So, this means that, right now, we are seeing C++ systems that use
> libtool (1.3 ?), and that work only on selected systems...

Actually, it probably only works on GNU/Linux and on some
installations of Solaris.  That's why libtool is being extended to
support C++ in general.

Unfortunately, even g++ won't work correctly on non-ELF systems.  I'm
talking about implicit instantiation of template static data members,
for example.  It is my understanding that this just can't be done
correctly on COFF, for example :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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

[Marc Espie]

On Mon, Jul 10, 2000 at 01:15:43PM -0700, Jason Merrill wrote:
> This is OK.  I would also welcome a patch to do a better job; perhaps
> factoring out some of gcc.c so that collect can tell if there is a default
> rule for a file.

> Jason

Part of the problem is that gcc does not know about that, as far as I can
tell.

Looking at `%o', it looks like anything it doesn't know about is passed
to collect2... along with other specific ld options.

Looks like a mess to me.

Any idea how to go about it ?

-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'

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

[Jason Merrill]

This is OK.  I would also welcome a patch to do a better job; perhaps
factoring out some of gcc.c so that collect can tell if there is a default
rule for a file.

Jason

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

[Marc Espie]

In article < or1z12arib.fsf@guarana.lsd.ic.unicamp.br > you write:
>On Jul 10, 2000, Marc Espie <Marc.Espie@liafa.jussieu.fr> wrote:

>> What this means is that libtool CAN'T support .lo on any platform
>> that relies on collect2 to do its job.

>The libtool multi-language branch, which is the only one that claims
>to support languages other than C, uses only .o files to name object
>files.  PIC object files are now stored in the .libs directory, and
>the .lo file now is a script that names the PIC and the non-PIC object
>files.

Any timeframe as to when this will be ready ?

The reason I'm asking is as follows:
ELF systems don't get through collect2, hence they don't even see the
problem.

So, this means that, right now, we are seeing C++ systems that use
libtool (1.3 ?), and that work only on selected systems... the selected systems
being now ubiquitous enough that there is little pressure to make the rest
of the world work...

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

[Alexandre Oliva]

On Jul 10, 2000, Marc Espie <Marc.Espie@liafa.jussieu.fr> wrote:

> What this means is that libtool CAN'T support .lo on any platform
> that relies on collect2 to do its job.

The libtool multi-language branch, which is the only one that claims
to support languages other than C, uses only .o files to name object
files.  PIC object files are now stored in the .libs directory, and
the .lo file now is a script that names the PIC and the non-PIC object
files.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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

[Ossama Othman]

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

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

[Marc Espie]

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.
Index: collect2.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/collect2.c,v
retrieving revision 1.96
diff -u -r1.96 collect2.c
--- collect2.c	2000/06/24 22:19:45	1.96
+++ collect2.c	2000/07/10 15:11:49
@@ -1222,7 +1222,7 @@
 	}
       else if ((p = rindex (arg, '.')) != (char *) 0
 	       && (strcmp (p, ".o") == 0 || strcmp (p, ".a") == 0
-		   || strcmp (p, ".so") == 0))
+		   || strcmp (p, ".so") == 0 || strcmp (p, ".lo") == 0))
 	{
 	  if (first_file)
 	    {
@@ -1237,7 +1237,7 @@
 		  *ld2++ = arg;
 		}
 	    }
-	  if (p[1] == 'o')
+	  if (p[1] == 'o' || p[1] == 'l')
 	    *object++ = arg;
 #ifdef COLLECT_EXPORT_LIST
 	  /* libraries can be specified directly, i.e. without -l flag.  */


The only problem is with special casing stuff... the only clean solution
I see is to get gcc aware that it is spewing stuff out to collect2, so that
it could flag stuff for collect2 explicitly...
-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'