From owner-freebsd-current Sat Apr 10 7: 6:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (Postfix) with ESMTP id BDC5C150A9; Sat, 10 Apr 1999 07:06:01 -0700 (PDT) (envelope-from peter@spinner.netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (Postfix) with ESMTP id 6825E1F4D; Sat, 10 Apr 1999 22:03:46 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Brian Feldman Cc: Mark Murray , jdp@FreeBSD.ORG, obrien@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Libraries with library dependancies In-reply-to: Your message of "Sat, 10 Apr 1999 09:34:36 -0400." Date: Sat, 10 Apr 1999 22:03:45 +0800 From: Peter Wemm Message-Id: <19990410140348.6825E1F4D@spinner.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Feldman wrote: > On Sat, 10 Apr 1999, Peter Wemm wrote: > > > Mark Murray wrote: > > > Hi > > > > > > I've been helping somebody along with getting the new libcrypt going, > > > and something has broken recently (post-egcs?), and I'm having a wee > > > problem debugging it. > > > > > > Libcrypt uses routines out of libmd (MD[45]* and SHA*), and a while > > > back (pre-egcs), it was possible to have an "LDADD+=-lmd" in libcrypt's > > > Makefile and have anything using libcrypt also automagically pick up the > > > -lmd dependancy requirement. This no longer seems to work: > > > > > > cc -O -pipe -I/usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl 5 -I > > /usr/obj/usr/src/gnu/usr.bin/perl/miniperl -I/usr/obj/usr/src/tmp/usr /inc > > lude -c /usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl5/mi nipe > > rlmain.c > > > cc -O -pipe -I/usr/src/gnu/usr.bin/perl/miniperl/../../../../contrib/perl 5 -I > > /usr/obj/usr/src/gnu/usr.bin/perl/miniperl -I/usr/obj/usr/src/tmp/usr /inc > > lude -static -o miniperl miniperlmain.o -lperl -lm -lcrypt > > ^^^^^^^^^^^^^^^ > > > /usr/obj/usr/src/tmp/usr/lib/libcrypt.a(crypt-shs.o): In function `crypt_ shs' > > : > > > crypt-shs.o(.text+0x11): undefined reference to `SHA_Init' > > > crypt-shs.o(.text+0x1f): undefined reference to `SHA_Update' > > > crypt-shs.o(.text+0x3c): undefined reference to `SHA_Update' > > > > > > The "undefined references" are all in libmd which is listed as above > > > in libcrypt's Makefile. > > > > This is only the case for -static.. Shared libraries have dependency > > information, static libraries do not. > > > > > I would hate to have to hunt down all usages of -lcrypt to add -lmd. > > > > It would affect ports too, breaking a lot of things that know about -lcrypt > > and have never heard of -lmd. > > > > The way I see it, you've got several choices.. > > > > 1) add -lmd for the cases where things are compiled static and leave the > > rest > > > > 2) compile libcrypt.a differently to libcrypt.so, ie: add in the md*.o and > > sha*.o static binaries into libcrypt by using SRCS+= sha.c in the !PIC case > > YES! Make the mdXXX symbols all weak, so libmd can be added manually! It's not going to be needed, it's a static library remember, they only get pulled in if needed. You could have mdXXX in your main program and it would still work, and you could add -lmd as well with no side effects. > > 3) help move ld.so to / so we can link everything dynamic.. :-) > > ld.so, ld-elf.so.1 SHOULD be in /, and fschg. They're definitely up > there in importance with the kernel. This would allow something nice: > /stand being a storage location for shared libraries. > > /stand meaning "standalone", hinting that only the root partition is > necessary to run a shared program if necessary... let's move /usr/lib > ELF libraries to /stand and keep all a.out and static libs (other than libgcc , > foo) in /usr/lib. > > On the other hand, maybe that's a little radical! What I would like is a minimal /lib, containing a few key libraries like libc.so, libutil.so, etc and have everything dynamic. This costs some speed, PIC code is slower than non-pic code since %ebx is "consumed". However, on the plus side you get to do a proper name server switch, can do dynamic crypt() selection on the fly based on a config file *and* have /sbin/init use it (for checking the single user password on a non-secure console), *and* have some support for alternative getpwnam() style interfaces (eg: usernames from a mysql database, if you're twisted enough, and having the entire OS support it). We can get the DNS resolver out of libc, possibly even YP too, etc. I measured it once, a long time ago early in the ELF development and (if I recall correctly), making /bin and /sbin shared freed up *more* space on the root partition than the extra shared libs and ld.so took up - ie: it saved disk space on /. Incidently, making / shared isn't the only way of doing it if you're prepared to get creative and compile static and dynamic libraries differently.... ie: dynamic libc uses dlopen() to implement the switches, while the static libc does a pipe/fork/etc and makes a pipe-based procedure call instead of a dlsym() direct call. Nah, that's much too radical, they'll never buy it. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message