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.Received on Thu Sep 04 2003 - 12:10:56 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:21 UTC