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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
