From owner-freebsd-ports Tue Apr 28 14:21:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA09906 for freebsd-ports-outgoing; Tue, 28 Apr 1998 14:21:31 -0700 (PDT) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA09410; Tue, 28 Apr 1998 14:20:00 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id RAA09202; Tue, 28 Apr 1998 17:15:40 -0400 (EDT) Date: Tue, 28 Apr 1998 17:15:39 -0400 (EDT) From: Snob Art Genre To: jkh@time.cdrom.com, ache@FreeBSD.ORG, torstenb@FreeBSD.ORG, tg@FreeBSD.ORG, steve@FreeBSD.ORG, peter@FreeBSD.ORG, ports@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you are receiving this message, it's because you have your name on a piece of software that is set up to link statically when it should be shared, or shared when it should be static, according to the message below from John Dyson. Some of your names came from the MAINTAINER variable in Makefiles from the ports collection; others came from CVS records of your modifications to relevant files. I apologize if you're not actually responsible for the code in question. Some offenders are: telnetd (?) tcsh pdksh zsh inetd ftpd make fingerd touch (?) cc cc1 cc1plus pine elm mail bash2 mutt There are almost certainly more; I recommend that you check whatever code you maintain with John's criteria in mind, in your copious spare time. ;-) If you have any questions, direct them to John. His email address is in the headers a few lines down from here. Ben "You have your mind on computers, it seems." ---------- Forwarded message ---------- Date: Wed, 22 Apr 1998 20:41:33 -0500 (EST) From: "John S. Dyson" To: Snob Art Genre Cc: toor@dyson.iquest.net Subject: Re: Static vs. dynamic linking (was Re: Using MD5 insted of DES ...) Snob Art Genre said: > On Wed, 22 Apr 1998, John S. Dyson wrote: > > > I'll scream terribly loudly if we even passingly consider making a > > shell shared!!! Shells are almost never advatageously made shared. > > Then why does our ports system build them incorrectly?! > Because I don't mess with the ports, and haven't done a very good job of making the above fact known. For maintenence, memory and speed reasons, one can seldom justify a shared shell. BTW, I use the ports extensively, but I tend to build and port the shells myself, probably for the issue that we are discussing. I haven't been watching this discussion carefully, but here are the costs of shared libs: fork() performance is slower. exec() performance is effectively slower (due to ld.so.) data and shared lib bss is packed much less effectively, and locality of reference, both at the sub-page level, and the page level is worse. Shared libs often require additional page table pages to map them. Here are the non-advantages: Shared libs don't help .text sharing, if a process has more than a few static occurances (shared .text works really well on our system.) Here are the advantages: Shared libs are great for processes where the libraries are large relative to the program size. Shared libs are great for processes that don't have many static or dynamic instances. My suggestions for programs that should probably not be linked with shared libs under any circumstances: Make, cp, cat, ls, *sh, cc, daemons that fork, .... mail readers, any (small) program invoked by make, or repeatedly invoked by shell scripts. If the shared libs are on /usr, any program that needs to be able to work without /usr mounted. Programs where it is likely slightly advantageous to link with shared libs: cc1, cc1plus, cpp, as, *roff, daemons that don't fork often, any X windows program (including those in any category), specialty programs that aren't used often... Programs where it is probably a toss-up: vi, *grep, other programs that don't fit the above criteria. Most of /usr/local, except for forking daemons. Reiterating, with clarification: More than 3-4 copies running at the same time: static Forks like a shell: static Must be able to run without shared libs: static If library CPU performance is critical: static Executes for a "long time", and doesn't fork often: shared Huge libraries: shared Not often used: shared -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message