Re: make buildworld br0ken in libutil
Mark Murray wrote: > > > Why does crypt need to be in libc? Not even a significant fraction of > > applications need crypt? > > Goes for very many libc components. Quite a lot of userland needs libcrypt > (not much as a proportion, but a non-insignificant number). This runs counter to my gut instinct of development which is to modularise code. Modularisation is accepted as a goal in all other areas of the tree it doesn't make sense to me why that thinking is being put to one side when it comes to the libraries. Maybe this should move to arch because I guess I'd like to see a actual design discussion as to why the current thinking is to collapse libraries into libc rather than to actually go the other way and modularise the code. Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
-On [2822 17:30], Ollivier Robert ([EMAIL PROTECTED]) wrote: >-=-=- >===> libexec/fingerd >cc -O -pipe -I/usr/obj/src/src/i386/usr/include -c /src/src/libexec/fingerd/fi >ngerd.c >cc -O -pipe -I/usr/obj/src/src/i386/usr/include -o fingerd fingerd.o -lutil >/usr/obj/src/src/i386/usr/lib/libutil.so: undefined reference to `crypt_set_form >at' >*** Error code 1 This should be fixed after my commit. -- Jeroen Ruigrok van der Werven Network- and systemadministrator <[EMAIL PROTECTED]>VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Morpheus in my Heart, your sand in my veins... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
-On [2822 17:30], Ollivier Robert ([EMAIL PROTECTED]) wrote: >Brian, I'm afraid you broke libutil... Every program using libutil now must >depend on libcrypt too. > >-=-=- >===> libexec/fingerd >cc -O -pipe -I/usr/obj/src/src/i386/usr/include -c /src/src/libexec/fingerd/fi >ngerd.c >cc -O -pipe -I/usr/obj/src/src/i386/usr/include -o fingerd fingerd.o -lutil >/usr/obj/src/src/i386/usr/lib/libutil.so: undefined reference to `crypt_set_form >at' >*** Error code 1 > >Stop in /src/src/libexec/fingerd. >*** Error code 1 I get the same thing, even with Brian's latest commit. -- Jeroen Ruigrok van der Werven Network- and systemadministrator <[EMAIL PROTECTED]>VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Haste makes waste... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
On Tue, 22 Aug 2000, Garrett Wollman wrote: > > -On [2822 17:30], Ollivier Robert ([EMAIL PROTECTED]) wrote: > >> Brian, I'm afraid you broke libutil... Every program using libutil now must > >> depend on libcrypt too. > > No. This is precisely why shared libraries have dependencies. For > static linking, what Brian has done Just Works. For dynamic linking, > libutil needs to depend on libcrypt to get its symbols resolved. > (Alternatively you might be able to do it with weak symbols.) Actually, the change breaks static linking for most programs that use one of the functions described in login_cap(3). This is because it adds login_setcrypt() to the existing spam in login_cap.c. This breaks limits, cron, crontab, inetd and sendmail in /usr/src alone. For dynamic linking, it only wastes time and space for the rarely actually used library. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
On Tue, 22 Aug 2000, Garrett Wollman wrote: > <<[EMAIL PROTECTED]> said: > > > -On [2822 17:30], Ollivier Robert ([EMAIL PROTECTED]) wrote: > >> Brian, I'm afraid you broke libutil... Every program using libutil now must > >> depend on libcrypt too. > > No. This is precisely why shared libraries have dependencies. For > static linking, what Brian has done Just Works. For dynamic linking, > libutil needs to depend on libcrypt to get its symbols resolved. > (Alternatively you might be able to do it with weak symbols.) Further, I cannot see how the make world _could_ be broken! This is strange, since I've never had the problem at all and have tested this change in several places (5.0 and 4.1). {"/home/green"}$ objdump --all-headers /usr/lib/libutil.so | grep NEEDED /usr/libexec/elf/objdump: /usr/lib/libutil.so: no symbols NEEDED libcrypt.so.2 > -GAWollman -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
< said: > -On [2822 17:30], Ollivier Robert ([EMAIL PROTECTED]) wrote: >> Brian, I'm afraid you broke libutil... Every program using libutil now must >> depend on libcrypt too. No. This is precisely why shared libraries have dependencies. For static linking, what Brian has done Just Works. For dynamic linking, libutil needs to depend on libcrypt to get its symbols resolved. (Alternatively you might be able to do it with weak symbols.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
> A growing libc makes static binaries grow and makes it more difficult to > strip out unneeded functionality from a minimalist system install. I'd > been inclined to try and move things the other way and strip stuff out > of libc into separate libraries but that's obviously not in vogue at the > moment. Static binaries don't pull in the whole of libc; they just pull in what they need, be it from libc or libcrypt, so size should not change. The _shared_ libc will get bigger, but we'll lose the shared libcrypto. > Why does crypt need to be in libc? Not even a significant fraction of > applications need crypt? Goes for very many libc components. Quite a lot of userland needs libcrypt (not much as a proportion, but a non-insignificant number). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
> -On [2822 17:30], Ollivier Robert ([EMAIL PROTECTED]) wrote: > >Brian, I'm afraid you broke libutil... Every program using libutil now must > >depend on libcrypt too. > > Alternatively the sentiment just rose why we couldn't just collapse the > crypt/hash functions of libcrypt into libc. Agreed! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
> > >> Alternatively the sentiment just rose why we couldn't just collapse the > > >> crypt/hash functions of libcrypt into libc. > > >> > > >> It would make sense. > > > > > >It would make even make more sense to convince the other BSD to do the same > > >(haven't checked recently what they do) and do the merge. > > > > I very much agree. > > > > Would it be sensible for the regular cypherpunks to discuss this with > > the NetBSD and OpenBSD brothers? > > > > Otherwise I would be willing to open this discussion on the appropriate > > lists. > > Is there any current policy on what libc is? It certainly isn't "libc" > as required by C and hasn't been for almost ever but there needs to be > some rational to its existence otherwise why not fold everything into > libc and not bother with any other libraries! > > A growing libc makes static binaries grow NOT! Static linking *only* brings in those symbols necessary for the file. It doesn't matter where those files are, they are only brought in if necessary. > and makes it more difficult to > strip out unneeded functionality from a minimalist system install. This is true. > I'd been inclined to try and move things the other way and strip stuff > out of libc into separate libraries but that's obviously not in vogue > at the moment. For what it's worth, I'm in agreement. The 'kitchen sink' approach, although easy tends to make stuff hard to maintain, since you end up with namespace collisions, and you may end up with something you are not aware of that conflicts with routines you are using inside your program. (Think of the recent weak symbol discussion where the library is not using the correct 'global' symbol for read as an example.) > Why does crypt need to be in libc? Not even a significant fraction of > applications need crypt? Agreed. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
On Tue, 22 Aug 2000 17:25:50 +0100, Paul Richards wrote: > Is there any current policy on what libc is? For some reason, I seem to remember Bruce Evans once calling it "the kitchen sink". :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
Jeroen Ruigrok van der Werven wrote: > > -On [2822 17:55], Ollivier Robert ([EMAIL PROTECTED]) wrote: > >According to Jeroen Ruigrok van der Werven: > >> Alternatively the sentiment just rose why we couldn't just collapse the > >> crypt/hash functions of libcrypt into libc. > >> > >> It would make sense. > > > >It would make even make more sense to convince the other BSD to do the same > >(haven't checked recently what they do) and do the merge. > > I very much agree. > > Would it be sensible for the regular cypherpunks to discuss this with > the NetBSD and OpenBSD brothers? > > Otherwise I would be willing to open this discussion on the appropriate > lists. Is there any current policy on what libc is? It certainly isn't "libc" as required by C and hasn't been for almost ever but there needs to be some rational to its existence otherwise why not fold everything into libc and not bother with any other libraries! A growing libc makes static binaries grow and makes it more difficult to strip out unneeded functionality from a minimalist system install. I'd been inclined to try and move things the other way and strip stuff out of libc into separate libraries but that's obviously not in vogue at the moment. Why does crypt need to be in libc? Not even a significant fraction of applications need crypt? Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
-On [2822 17:55], Ollivier Robert ([EMAIL PROTECTED]) wrote: >According to Jeroen Ruigrok van der Werven: >> Alternatively the sentiment just rose why we couldn't just collapse the >> crypt/hash functions of libcrypt into libc. >> >> It would make sense. > >It would make even make more sense to convince the other BSD to do the same >(haven't checked recently what they do) and do the merge. I very much agree. Would it be sensible for the regular cypherpunks to discuss this with the NetBSD and OpenBSD brothers? Otherwise I would be willing to open this discussion on the appropriate lists. -- Jeroen Ruigrok van der Werven Network- and systemadministrator <[EMAIL PROTECTED]>VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl The administration of justice is the firmest pillar of government... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
According to Jeroen Ruigrok van der Werven: > Alternatively the sentiment just rose why we couldn't just collapse the > crypt/hash functions of libcrypt into libc. > > It would make sense. It would make even make more sense to convince the other BSD to do the same (haven't checked recently what they do) and do the merge. -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED] The Postman hits! The Postman hits! You have new mail. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld br0ken in libutil
-On [2822 17:30], Ollivier Robert ([EMAIL PROTECTED]) wrote: >Brian, I'm afraid you broke libutil... Every program using libutil now must >depend on libcrypt too. Alternatively the sentiment just rose why we couldn't just collapse the crypt/hash functions of libcrypt into libc. It would make sense. -- Jeroen Ruigrok van der Werven Network- and systemadministrator <[EMAIL PROTECTED]>VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl I walk, I walk alone, into the promised land... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message