libraries search path adjusting proposal

[(GalaxyMaster)]

Hello, everyone!

I think that current logic of searching for libraries in ld is not
perfect :( Imagine for example the next situation: we have a static
library libdummy.a in the /usr/lib and the shared library libdummy.so in
the /lib -- if we will try to link executable with -ldummy, we will
constantly get static link with libdummy.a.

We, Openwall Team, implemented and tested included patch for 3 months
and have found no problems with it. The proposed logic follows:

1. if this is not an archive, try to open it in current directory first
2. scan search path for dynamic objects (*)
3. scan search path for archive objects

(*) - if the pathname in the search path comes from command line (i.e.
      was specified via -L command line switch, then if opening of the
      dynamic object fails, try to open archive object.  This is done
      because else we will break ability to build executables with
      included libraries whose versions differ from the system ones.

-- 
(GalaxyMaster)
Openwall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils-2.14.90.0.8-owl-searchpath.diff
Type: application/octet-stream
Size: 3645 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040507/82c8690f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20040507/82c8690f/attachment.sig>