Re: problems with ld from binutils 2.5.2l.20

Re: problems with ld from binutils 2.5.2l.20

[H.J. Lu]

> 
>  > For the GNU linker, -L applies to all -l's.
> 
> This behavior is wrong. First, it makes no sense, since the order of
> -l's is significant, and second, it makes it impossible to control
> which copies of which libraries are linked with, which could be
> significant. 
> 

The problem is twofold:

1. gcc will re-arrange the order of -L's and -l's. It puts -L's ahead of
   -l's.
2. One -L list is used fo all libraries in the linker.

We have to change both gcc and ld to do the "right" thing.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: problems with ld from binutils 2.5.2l.20

[Ian Lance Taylor]

   From: hjl@nynexst.com (H.J. Lu)
   Date: Thu, 3 Aug 95 9:49:19 EDT

   >  > For the GNU linker, -L applies to all -l's.
   > 
   > This behavior is wrong. First, it makes no sense, since the order of
   > -l's is significant, and second, it makes it impossible to control
   > which copies of which libraries are linked with, which could be
   > significant. 

   The problem is twofold:

   1. gcc will re-arrange the order of -L's and -l's. It puts -L's ahead of
      -l's.
   2. One -L list is used fo all libraries in the linker.

   We have to change both gcc and ld to do the "right" thing.

Just as a side note, the GNU linker behaviour is consistent with the
SunOS linker behaviour.  However, I agree that this should probably be
changed.

Ian

Re: problems with ld from binutils 2.5.2l.20

[Ian Lance Taylor]

   From: hjl@nynexst.com (H.J. Lu)
   Date: Thu, 3 Aug 95 9:49:19 EDT

   >  > For the GNU linker, -L applies to all -l's.
   > 
   > This behavior is wrong. First, it makes no sense, since the order of
   > -l's is significant, and second, it makes it impossible to control
   > which copies of which libraries are linked with, which could be
   > significant. 
   > 

   The problem is twofold:

   1. gcc will re-arrange the order of -L's and -l's. It puts -L's ahead of
      -l's.
   2. One -L list is used fo all libraries in the linker.

   We have to change both gcc and ld to do the "right" thing.

I started to think about implementing this, but then I realized that I
don't understand it.  As far as I can tell, it only makes a difference
when an archive does not exist.

Support you run
    ld -Lfoo -lfoo -Lbar -lbar
The proposed change appears to argue that the -Lbar should not apply
to the -lfoo.  However, that only matters if foo/libfoo.a does not
exist.

So, it does not make it impossible to control which libraries are used
in the link.  In fact, this change would not affect what libraries are
included in the link at all, except that the linker would sometimes
fail in cases where it currently succeeds.

It doesn't seem worth making this change.  As I noted earlier, the
current linker behaviour is compatible with the SunOS linker.

Ian

Re: problems with ld from binutils 2.5.2l.20

[Richard Stallman]

    Support you run
	ld -Lfoo -lfoo -Lbar -lbar
    The proposed change appears to argue that the -Lbar should not apply
    to the -lfoo.  However, that only matters if foo/libfoo.a does not
    exist.

That is true.

What this shows is that even if the order of options were not rearranged,
the -L feature is insufficient for controlling which libraries are used,
for the reason that it can only add to the end of the search list.

So I guess we might as well not change this unless/until we also make
it powerful enough to alter the search list in more flexible ways.
I don't know of an urgent need to do that.

Re: problems with ld from binutils 2.5.2l.20

[Wolfgang Stukenbrock]

> 
>     Support you run
> 	ld -Lfoo -lfoo -Lbar -lbar
>     The proposed change appears to argue that the -Lbar should not apply
>     to the -lfoo.  However, that only matters if foo/libfoo.a does not
>     exist.
> 
> That is true.
> 
> What this shows is that even if the order of options were not rearranged,
> the -L feature is insufficient for controlling which libraries are used,
> for the reason that it can only add to the end of the search list.
> 
> So I guess we might as well not change this unless/until we also make
> it powerful enough to alter the search list in more flexible ways.
> I don't know of an urgent need to do that.
> 

I don't think it will be a good idea to change this in any case, because
some makefile rely on the fact, that all -L directives are scanned before
any other processing is done. The ld would get incompartible to the standard
semantics!

-- 
 Wolfgang Stukenbrock