collect2 always built?

collect2 always built?

[Todd Vierling]

Is this an egcs thing or a gcc 2.8 thing?... Under egcs, --with-gnu-ld in
the configuration causes collect2 ($(libsubdir)/ld) to be built and
installed at all times as opposed to gcc 2.7.x', where the GNU ld is assumed
to handle constructors and destructors of static items properly.  Which is
correct?  I'm currently just deleting the installed collect2 binary and all
works fine.

=====
===== Todd Vierling (Personal tv@pobox.com) =====
== "There's a myth that there is a scarcity of justice to go around, so
== that if we extend justice to 'those people,' it will somehow erode the
== quality of justice everyone else receives."  -- Maria Price

Re: collect2 always built?

[Jeffrey A Law]

  In message < Pine.NEB.3.96.980202114517.22769A-100000@like.duh.org >you write:
  > Is this an egcs thing or a gcc 2.8 thing?... Under egcs, --with-gnu-ld in
  > the configuration causes collect2 ($(libsubdir)/ld) to be built and
  > installed at all times as opposed to gcc 2.7.x', where the GNU ld is assume> d
  > to handle constructors and destructors of static items properly.  Which is
  > correct?  I'm currently just deleting the installed collect2 binary and all
  > works fine.
You need collect2 -- else you're going to start running into problems
with shared library ctors/dtors and exception handling initialization
code.

collect2 should always be installed now, even if you're using gnu-ld.

jeff

Re: collect2 always built?

[Joe Buck]

> Is this an egcs thing or a gcc 2.8 thing?... Under egcs, --with-gnu-ld in
> the configuration causes collect2 ($(libsubdir)/ld) to be built and
> installed at all times as opposed to gcc 2.7.x', where the GNU ld is assumed
> to handle constructors and destructors of static items properly.  Which is
> correct?  I'm currently just deleting the installed collect2 binary and all
> works fine.

collect is needed even with GNU ld if you want the -frepo option to work.
But then, you might not care about -frepo.

Re: collect2 always built?

[Mumit Khan]

Joe Buck <jbuck@synopsys.com> writes:
> 
> collect is needed even with GNU ld if you want the -frepo option to work.
> But then, you might not care about -frepo.

And, as I understand it, there is the question of exception handling as 
well on some platforms.

Mumit

Re: collect2 always built?

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

> You need collect2 -- else you're going to start running into problems
> with shared library ctors/dtors and exception handling initialization
> code.

This is not true of ELF targets; they only use collect2 for -frepo handling
and demangling of error messages.

Jason

Re: collect2 always built?

[Joe Buck]

> This is not true of ELF targets; they only use collect2 for -frepo handling
> and demangling of error messages.

If someone has ELF and the latest GNU ld, is there ever a situation where
they would want to use -frepo?  (This question is intended for
implementers familiar with template instantiation details only).
It seems that all -frepo will do is take multiple passes to produce the
same executable that could have been produced without it in one pass.

Since GNU ld does demangling of error messages, it would seem that there
is no reason to use collect on Linux/ELF.

Re: collect2 always built?

[Alexandre Oliva]

Joe Buck writes:

>> This is not true of ELF targets; they only use collect2 for -frepo handling
>> and demangling of error messages.

> If someone has ELF and the latest GNU ld, is there ever a situation where
> they would want to use -frepo?

Once, I made a package that contained a couple of libraries, with lots
of template code.  I used the .rpo files to select myself which files
should contain instantiations of templates, so that I could control
library inter-dependencies myself.

In fact, this wouldn't require collect2 at all, since I did myself the
work collect2 would have done, but I can imagine a situation where one
would distribute multiple libraries, and would like these libraries
not to contain duplicated code (so that a base library could be
upgraded without upgrading a dependent one).

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: collect2 always built?

[Mumit Khan]

Joe Buck <jbuck@synopsys.com> writes:
> If someone has ELF and the latest GNU ld, is there ever a situation where
> they would want to use -frepo?  

I ran into a situation where this was certainly useful: In a particular
project that uses lots of templates, the size of the build dir tree
went up to about 220M, whereas using -frepo and library closure, it's
around 130M. That's a big difference; however, given a choice between the
two, I'd take the smart linker approach any day. 

> Since GNU ld does demangling of error messages, it would seem that there
> is no reason to use collect on Linux/ELF.

Ditto for Win32 (PE-COFF). 

Mumit

Re: collect2 always built?

[Mike Stump]

> From: Joe Buck <jbuck@synopsys.com>
> To: jason@cygnus.com (Jason Merrill)
> Date: Tue, 3 Feb 98 9:53:58 PST

> If someone has ELF and the latest GNU ld, is there ever a situation where
> they would want to use -frepo?

I think so.  Speed.  I predict that there are cases where using -frepo
will yield smaller .o files, and will take less time to generate them
and less time to link them.

Though I admit I have never benchmarked it.  Also, this is probably
only an issue for large projects (it takes an hour to link, type
ones).

Re: collect2 always built?

[Joe Buck]

> > If someone has ELF and the latest GNU ld, is there ever a situation where
> > they would want to use -frepo?
> 
> I think so.  Speed.  I predict that there are cases where using -frepo
> will yield smaller .o files, and will take less time to generate them
> and less time to link them.

I would be amazed.  My experience with -frepo is that it is dog-slow, and
with 2.7.2 I saw as many as ten link-recompile passes on relatively small
programs that used STL.  This should be better (fewer passes) with egcs
because templates are inlined more readily, but where templates call other
templates the work can be considerable.

> Though I admit I have never benchmarked it.

That is quite apparent.

> Also, this is probably
> only an issue for large projects (it takes an hour to link, type
> ones).

There are other problems with -frepo for large projects, having to do with
library reuse.

Re: collect2 always built?

[Mike Stump]

> From: Joe Buck <jbuck@Synopsys.COM>
> To: mrs@wrs.com (Mike Stump)
> Date: Tue, 3 Feb 98 12:10:50 PST
> Cc: jason@cygnus.com, jbuck@Synopsys.COM, egcs@cygnus.com

> > > If someone has ELF and the latest GNU ld, is there ever a situation where
> > > they would want to use -frepo?
> > 
> > I think so.  Speed.  I predict that there are cases where using -frepo
> > will yield smaller .o files, and will take less time to generate them
> > and less time to link them.

> I would be amazed.  My experience with -frepo is that it is dog-slow, and
> with 2.7.2 I saw as many as ten link-recompile passes on relatively small
> programs that used STL.

Any what is the speed of the second recompile?  How does this compare
to the non-repo compile?  I know the first one will be slow with repo.

If you don't have any numbers, then maybe someone with a larger C++ pt
heavy code base would be willing to try...

Re: collect2 always built?

[Mike Simons]

[sorry about the references... I don't remember who the inner 
quotes are from]

Mike Stump wrote:
>I think Joe Buck wrote:
>>>> If someone has ELF and the latest GNU ld, is there ever a situation where
>>>> they would want to use -frepo?
>>> 
>>> I think so.  Speed.  I predict that there are cases where using -frepo
>>> will yield smaller .o files, and will take less time to generate them
>>> and less time to link them.
> 
>> I would be amazed.  My experience with -frepo is that it is dog-slow, and
>> with 2.7.2 I saw as many as ten link-recompile passes on relatively small
>> programs that used STL.

  Using -frepo is *much* faster in my limited experience on second, 
third, and fifty-ith compile... when it works at all.
  Small examples it seems to work fine... I kinda gave up after reading 
some comments about how it was "not supposed to work" on ELF systems.

> Any what is the speed of the second recompile?  How does this compare
> to the non-repo compile?  I know the first one will be slow with repo.
> 
> If you don't have any numbers, then maybe someone with a larger C++ pt
> heavy code base would be willing to try...

  I was trying use -frepo in our source back with egcs-1.0.0 ... 
In particular I was trying to use -frepo to produce some libraries,
then use those libraries to produce our main binaries.  We are 
using basic STL stuff all over the place.
  The linker was failing to do the final link on our libraries... 
this was on both linux and solaris.  I didn't have time to produce a
bug report because gdb was breaking all over the place... <gerr>

  If anyone is interested in looking into it, I'll try to produce a 
example this again this weekend?

-- 

    Later,
      Mike Simons
      Science Applications International Corporation
      msimons@saic1.com                  703-925-5674

Re: collect2 always built?

[Mike Stump]

> To: egcs@cygnus.com
> Date: Tue, 03 Feb 1998 13:53:35 -0600
> From: Mumit Khan <khan@xraylith.wisc.edu>

> Joe Buck <jbuck@synopsys.com> writes:

> I ran into a situation where this was certainly useful: In a
> particular project that uses lots of templates, the size of the
> build dir tree went up to about 220M, whereas using -frepo and
> library closure, it's around 130M. That's a big difference; however,
> given a choice between the two, I'd take the smart linker approach
> any day.

Very useful data point, thanks.  I was wondering if you had build
times for a second build for repo and non-repo.  I might guess 70%
faster, but would be nice to get a confirmation of this guess for a
real project.