always use collect2

always use collect2

[Arvind Sankar]

I have a SPARC machine running UNIX SVR4.

Why is USE_COLLECT2 always defined? Doesnt egcs work with the binutils
2.8.1 linker?
If I have to use collect2, how do I tell it to call the binutils linker
rather than the default one on my system, which it seems to find in
/usr/ccs/bin? The binutils ld is earlier in my PATH when collect2 was
built. collect2 calling /usr/ccs/bin/ld causes problems because I want
to pass certain options to binutils-ld which /usr/ccs/bin/ld does not
support.

Mon Aug 11 14:15:02 1997  Jeffrey A Law  (law@cygnus.com)

        * Makefile.in (USE_COLLECT2): Always use collect2.
        (collect2): Depend on and link in hash.o and tlink.o.
        (tlink.o, hash.o): Add dependencies.

-- arvind

Re: always use collect2

[Jeffrey A Law]

  In message < 19980221105411.A26167@kailash.cse.iitb.ernet.in >you write:
  > I have a SPARC machine running UNIX SVR4.
  > 
  > Why is USE_COLLECT2 always defined? Doesnt egcs work with the binutils
  > 2.8.1 linker?
It still works with the 2.8.1 linker, but collect2 is still needed
to deal with certain shared library issues.

jeff

gcc m68k: pc-relative addressing for code?

[Michael Schwingen]

Hi,

is it possible to have gcc create output which only uses PC-relative
addressing for code references? 

I need this for ROM code which is moved around during PMMU initialization -
however, variables are in a constant place in RAM and shall *not* be
referenced PC-relative, so -fpic or -fPIC seems not to be usable in this
case, and the addressing via GOT seems to be a bit inefficient, too - the
PC-relative addressing mode would be better (32k code limit is not a
problem).

(a nice thing to have would be if all variables could be referenced relative
to an address register, which is *not* reloaded by gcc - however, I can live
without).

cu
Michael
-- 
In the beginning there was nothing, which exploded.

Re: gcc m68k: pc-relative addressing for code?

[Jeffrey A Law]

  In message < 19980221120121.42072@nemesis >you write:
  > is it possible to have gcc create output which only uses PC-relative
  > addressing for code references? 
Unfortunately I do not believe such an option exists on the m68k.

jeff

Re: gcc m68k: pc-relative addressing for code?

[Philippe De Muyter]

> 
>   In message < 19980221120121.42072@nemesis >you write:
>   > is it possible to have gcc create output which only uses PC-relative
>   > addressing for code references? 
> Unfortunately I do not believe such an option exists on the m68k.

Do you mean `m68k', or `m68k port of gcc' ? Does that imply that it exists
for other gcc targets ?

Re: gcc m68k: pc-relative addressing for code?

[Jeffrey A Law]

  In message < 199802220651.HAA10158@mail.macqel.be >you write:
  > > 
  > >   In message < 19980221120121.42072@nemesis >you write:
  > >   > is it possible to have gcc create output which only uses PC-relative
  > >   > addressing for code references? 
  > > Unfortunately I do not believe such an option exists on the m68k.
  > 
  > Do you mean `m68k', or `m68k port of gcc' ? Does that imply that it exists
  > for other gcc targets ?
Some ports use pc-relative addressing modes to access items in the
constant pool or readonly data.

Such features require machine dependent work, which I don't think
was ever submitted for teh m68k.
jeff

Re: always use collect2

[Alexandre Oliva]

Arvind Sankar writes:

> Why is USE_COLLECT2 always defined?

Because it is needed in order to implement the C++ template repository
mechanism (-frepo)

> Doesnt egcs work with the binutils 2.8.1 linker?

It does, but it's not enough.

> If I have to use collect2, how do I tell it to call the binutils linker
> rather than the default one on my system, which it seems to find in
> /usr/ccs/bin?

Create a link named `real-ld' to the ld program you wish to use in the
same directory where `cc1' lives.

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

Re: always use collect2

[Andi Kleen]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

> Arvind Sankar writes:
> 
> > Why is USE_COLLECT2 always defined?
> 
> Because it is needed in order to implement the C++ template repository
> mechanism (-frepo)

Does this mean that collect is not needed when ELF and recent GNU binutils
(to sort out duplicate template instantiations) are used?
It runs per default on my Linux ELF/binuntils 2.8.x too.

-Andi

Re: always use collect2

[Jeffrey A Law]

  In message < k2pvkfubzg.fsf@zero.aec.at >you write:
  > Does this mean that collect is not needed when ELF and recent GNU binutils
  > (to sort out duplicate template instantiations) are used?
  > It runs per default on my Linux ELF/binuntils 2.8.x too.
collect2 is always needed, regardless of the object file format.

It's necessary to deal with some shared library and EH issues.

jeff

Re: always use collect2

[Richard Henderson]

On Sun, Feb 22, 1998 at 12:07:21PM -0700, Jeffrey A Law wrote:
> It's necessary to deal with some shared library and EH issues.

No, I'm pretty sure it's just repo for gnu ld on elf.
But since it isn't doing anything it also shouldn't get
in the way, so it should be left in the loop.


r~

Re: always use collect2

[Jeffrey A Law]

  In message < 19980222124721.49413@dot.cygnus.com >you write:
  > On Sun, Feb 22, 1998 at 12:07:21PM -0700, Jeffrey A Law wrote:
  > > It's necessary to deal with some shared library and EH issues.
  > 
  > No, I'm pretty sure it's just repo for gnu ld on elf.
  > But since it isn't doing anything it also shouldn't get
  > in the way, so it should be left in the loop.
Talk to Jason -- he explained the shlib and EH dependencies
to me a while ago (I've forgotten the details).

jeff

Re: always use collect2

[ak]

On Sun, Feb 22, 1998 at 09:47:21PM +0100, Richard Henderson wrote:
> On Sun, Feb 22, 1998 at 12:07:21PM -0700, Jeffrey A Law wrote:
> > It's necessary to deal with some shared library and EH issues.
> 
> No, I'm pretty sure it's just repo for gnu ld on elf.
> But since it isn't doing anything it also shouldn't get
> in the way, so it should be left in the loop.

I remember seeing it in top, so it must be doing something.

-Andi

Re: always use collect2

[Jason Merrill]

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

>   In message < 19980222124721.49413@dot.cygnus.com >you write:
>> On Sun, Feb 22, 1998 at 12:07:21PM -0700, Jeffrey A Law wrote:
>> > It's necessary to deal with some shared library and EH issues.
>> 
>> No, I'm pretty sure it's just repo for gnu ld on elf.
>> But since it isn't doing anything it also shouldn't get
>> in the way, so it should be left in the loop.

> Talk to Jason -- he explained the shlib and EH dependencies
> to me a while ago (I've forgotten the details).

No, Richard is right.  On ELF targets, it's just for repo and demangling
the linker error messages.

Jason

Re: always use collect2

[Jeffrey A Law]

  In message < u9k9anhsq7.fsf@yorick.cygnus.com >you write:
  > >>>>> Jeffrey A Law <law@cygnus.com> writes:
  > 
  > >   In message < 19980222124721.49413@dot.cygnus.com >you write:
  > >> On Sun, Feb 22, 1998 at 12:07:21PM -0700, Jeffrey A Law wrote:
  > >> > It's necessary to deal with some shared library and EH issues.
  > >> 
  > >> No, I'm pretty sure it's just repo for gnu ld on elf.
  > >> But since it isn't doing anything it also shouldn't get
  > >> in the way, so it should be left in the loop.
  > 
  > > Talk to Jason -- he explained the shlib and EH dependencies
  > > to me a while ago (I've forgotten the details).
  > 
  > No, Richard is right.  On ELF targets, it's just for repo and demangling
  > the linker error messages.
I'm obviously confused then :-)  

Thanks for clearing things up.

jeff