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: 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 [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
make buildworld br0ken in libutil
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 -=-=- -- 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
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: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
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 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
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 [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
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 Tue, 22 Aug 2000 17:53:09 +0200, Jeroen Ruigrok van der Werven [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.) -GAWollman 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 Tue, 22 Aug 2000 17:53:09 +0200, Jeroen Ruigrok van der Werven
[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
