From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lance Taylor <ian@cygnus.com>
To: hjl@nynexst.com
Cc: dholland@husc.harvard.edu, gas2@cygnus.com
Subject: Re: problems with ld from binutils 2.5.2l.20
Date: Mon, 11 Sep 1995 12:34:00 -0000
Message-id: <199509111934.PAA19698@sanguine.cygnus.com>
References: <9508031349.AA10077@nynexst.com>
X-SW-Source: 1995/msg00164.html

   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