From owner-freebsd-hackers Tue Apr 25 08:45:29 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA18334 for hackers-outgoing; Tue, 25 Apr 1995 08:45:29 -0700 Received: from netcom23.netcom.com (root@netcom23.netcom.com [192.100.81.137]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA18323 for ; Tue, 25 Apr 1995 08:45:24 -0700 From: patl@asimov.lashley.slip.netcom.com Received: from lashley.slip.netcom.com by netcom23.netcom.com (8.6.12/Netcom) id IAA06753; Tue, 25 Apr 1995 08:44:42 -0700 Received: by lashley.slip.netcom.com (5.x/SMI-SVR4) id AA10160; Tue, 25 Apr 1995 08:48:41 -0700 Date: Tue, 25 Apr 1995 08:48:41 -0700 Message-Id: <9504251548.AA10160@lashley.slip.netcom.com> To: roberto@blaise.ibp.fr, nate@trout.sri.MT.net Subject: Re: benchmark hell.. Cc: hackers@FreeBSD.org X-Sun-Charset: US-ASCII Sender: hackers-owner@FreeBSD.org Precedence: bulk |> > > To the contrary, *make*ing the Linux shlib's is a pain in the butt, |> > > while it's a very easy process to create a SunOS-like shlib. |> > |> > That will change with the introduction of the ELF format for binaries. |> > They will have the same ease of use and it seems not that slower either from |> > the report I got from my Linux's friends. |> |> Actually, folks I have talked to have given me the exact opposite |> report. And some people on the newsgroups have complained about the |> switch to ELF binaries since they are significantly slower than the |> original shlib implementation. |> |> I think our shlib implementatio is still probably slower than the ELF |> shlib stuff, but I suspect it's not much anymore. One thing that helps quite a bit, independant of object file format, is what the Sun folks call a 'symbol hiding linker'. Basicly, it is linker extensions that let the developer specify which symbols are to be exported, and which ones are local to the library itself. Reducing the final symbol table size speeds the dynamic linking at execution time. -Pat