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

2003-09-04 Thread Ruslan Ermilov
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.

 The only reason while I still think we should support both
 /lib and /usr/lib in cc(1) and ld(1) by default is to allow
 our users to have /usr symlinked somethere, otherwise relative
 symlinking from /usr/lib to ../../lib does not work, and we
 are back to that endless thread.
 
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.

- Works without any more modifications to GCC.  ld(1)
  hacks can go away too.

Please review.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.389
diff -u -r1.389 Makefile.inc1
--- Makefile.inc1   1 Sep 2003 06:43:24 -   1.389
+++ Makefile.inc1   4 Sep 2003 19:30:19 -
@@ -227,6 +227,7 @@
 # world stage
 WMAKEENV=  ${CROSSENV} \
DESTDIR=${WORLDTMP} \
+   SHLIBDIRPREFIX=${WORLDTMP} \
INSTALL=sh ${.CURDIR}/tools/install.sh \
PATH=${TMPPATH}
 WMAKE= ${WMAKEENV} ${MAKE} -f Makefile.inc1
Index: share/mk/bsd.lib.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.lib.mk,v
retrieving revision 1.153
diff -u -r1.153 bsd.lib.mk
--- share/mk/bsd.lib.mk 4 Sep 2003 04:29:11 -   1.153
+++ share/mk/bsd.lib.mk 4 Sep 2003 19:34:08 -
@@ -208,9 +208,10 @@
${_INSTALLFLAGS} ${_SHLINSTALLFLAGS} \
${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}
 .if defined(SHLIB_LINK)
-   ln -fs ${SHLIB_NAME} ${DESTDIR}${SHLIBDIR}/${SHLIB_LINK}
-.if (${LIBDIR} != ${SHLIBDIR})
-   ln -fs ${LIBDIR:C|/[^/]+|/..|g:S|^/||}${SHLIBDIR}/${SHLIB_NAME} \
+.if ${SHLIBDIR} == ${LIBDIR}
+   ln -fs ${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK}
+.else
+   ln -fs ${SHLIBDIRPREFIX}${SHLIBDIR}/${SHLIB_NAME} \
${DESTDIR}${LIBDIR}/${SHLIB_LINK}
 .endif
 .endif


pgp0.pgp
Description: PGP signature


Re: /lib/foo.so.X - /usr/lib/foo.so

2003-09-04 Thread 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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: /lib/foo.so.X - /usr/lib/foo.so

2003-09-04 Thread Dan Nelson
In the last episode (Sep 04), David O'Brien said:
 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:

I haven't updated in a while, but my Debian unstable box has ..

$ find /usr/lib/*.so -type l -ls | grep  /lib | wc -l
24

.. symlinks back to /lib. 

-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: /lib/foo.so.X - /usr/lib/foo.so

2003-09-04 Thread Mark Kettenis
   Date: Thu, 4 Sep 2003 14:10:50 -0700
   From: David O'Brien [EMAIL PROTECTED]

   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 )

Speaking as a (former) glibc developer (a true convert nowadays):

Well, libc is a special case since there are a few functions that
aren't provided by the shared libc, but are always linked statically.
Linux does this to be compatible with the System V ABI.

The whole thing is actually pointless since most interfaces in libc.so
aren't compatible with the System V ABI, so it's nothing but a
historical fart nowadays.

Anyway, I think you'll see a symlink for /usr/lib/libm.so.  At least
my SuSE Linux 8.2 does have it.

Mark


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]