/lib/foo.so.X -> /usr/lib/foo.so

[David O'Brien]

On Thu, Sep 04, 2003 at 11:27:15PM +0300, Ruslan Ermilov wrote:
> On Thu, Sep 04, 2003 at 09:58:39PM +0300, Ruslan Ermilov wrote:
> [...]
> > The patch is not a problem (attached).  I've been looking at
> > how our friends do this.  NetBSD has symlinks in /usr/lib to
> > /lib, both to .so and .so.X, and their cc(1) and ld(1) don't
> > look things in /lib.  Linux looks things up in both /lib and
> > /usr/lib, and does not have symlinks from /usr/lib to /lib.
> > 
> There is a sad typo above: Linux *does* have symlinks from
> /usr/lib to /lib, so both use /usr/lib for linking.

What version of Linux are you using?  SuSE Enterprise Linux 8, and Red
Hat Enterprise Linux 3 both do not have symlinks for libs from /usr/lib
to /lib.  They use a different machanism:


    suse# cat /usr/lib/libc.so
        /* GNU ld script
           Use the shared library, but some functions are only in
           the static library, so try that secondarily.  */
        GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

 
> Not that I'm completely happy with introducing yet another
> variable in bsd.lib.mk, but the attached patch:
> 
> - Leaves only one set of .so symlinks in /usr/lib.
> 
>   Benefits: all other systems that use both /lib and /usr/lib
>   (that I've been able to test) have .so links in /usr/lib
>   only, and use them for linking; GCC in ports will like this
>   better.
> 
> - Uses absolute paths in .so symlinks.
> 
>   Benefit: works for people who have their /usr symlinked
>   somewhere.

A true benefit.