From owner-freebsd-hackers Thu Aug 28 00:09:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA13572 for hackers-outgoing; Thu, 28 Aug 1997 00:09:51 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA13559 for ; Thu, 28 Aug 1997 00:09:46 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.8.5/8.6.6) id AAA15241; Thu, 28 Aug 1997 00:09:45 -0700 (PDT) Date: Thu, 28 Aug 1997 00:09:45 -0700 (PDT) From: Sean Eric Fagan Message-Id: <199708280709.AAA15241@kithrup.com> To: hackers@freebsd.org Subject: Re: shared libraries? References: <199708280507.AAA07664@dyson.iquest.net> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you write: >I'm not arguing, just asking, why would using shared libraries hurt? For several reasons: 1. the position-independent code is much worse, performance- and size-wise, than the non-PIC versions. On the x86, this is almost worst case, because of the lack of general-purpose registers. 2. When using a shared library, the ENTIRE IMAGE gets pulled in; when using a normal library, only the needed bits are pulled in. Programs that need only a few routines may, as a result, be larger because of the extra baggage. Yes, it's shared, but it still takes up some space. And if the program in question is used a lot (e.g., /bin/sh), then the program text will be shared anyway, thus making up for the lack of shared library. 3. The shared library code has to jump through some hoops in order to allow for user-redefined functions. E.g., malloc(). This also results in some more performance loss. The *big* advantage of shared libraries is that *disk space* is smaller. But this does come at a cost.