From owner-freebsd-emulation Fri Dec 6 16:07:45 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA19776 for emulation-outgoing; Fri, 6 Dec 1996 16:07:45 -0800 (PST) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA19770 for ; Fri, 6 Dec 1996 16:07:38 -0800 (PST) Received: from cent.cs.tu-berlin.de (loewis@cent.cs.tu-berlin.de [130.149.22.20]) by mail.cs.tu-berlin.de (8.6.13/8.6.12) with ESMTP id BAA14802; Sat, 7 Dec 1996 01:07:03 +0100 From: "Martin v.Loewis" Received: (from loewis@localhost) by cent.cs.tu-berlin.de (8.8.4/8.8.4) id BAA02982; Sat, 7 Dec 1996 01:06:52 +0100 (MET) Message-Id: <199612070006.BAA02982@cent.cs.tu-berlin.de> Subject: Re: status of windows, dos and svr4 emulation To: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.) Date: Sat, 7 Dec 1996 01:06:48 +0100 (MET) Cc: freebsd-emulation@FreeBSD.org In-Reply-To: <32A79D8D.75BC@fps.biblos.unal.edu.co> from "Pedro Giffuni S." at Dec 5, 96 08:14:15 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-emulation@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > of shared libs and other such resources. But FreeBSD's a.out's are more > > than capable of handling such beasties. That is one of the principle > > reasons why it has taken FreeBSD "so long" to implement elf. > > Linix is proud of thier ELFs, I have never understood why. I have hea= > rd > > that thier a.outs are not as robust, but I can't confirm it. > >=20 > The exact term someone on this list used was "sucks" :). Yes fbsd is > very superior in this sense to Linux, what I wonder is if I should > prefer elf binaries under Linux=B4s emulation. It probably is the same > thing. Out of curiosity, can somebody explain (or point me to) what exactly makes the FreeBSD a.out superior to similar formats found on other systems? Specifically, I'd like to know the following things: - How does it deal with relocation in shared libraries? Does it require the shared libraries to be at a fixed address? If not, does it relocate the image? If so, is the sharing among different processes preserved? If not, how does it deal with global variables being at different places? - Does it support construction of global C++ objects in the library? (I.e. is there per-library startup code) - Does it support libdl? I.e. can new objects be loaded after program started? - How does it do versioning? Is there a concept of major and minor versions? If a program requests a version, what library versions would be offered? Is the location of the library stored in the image? How does it deal with interdependecies between shared images? I.e. suppose I have libfoo.1, libfoo.2 and libbar.1. libbar.1 depends on libfoo.1, and libfoo.1 and libfoo.2 are mutually incompatible. Can I build new programs so that they get linked with libfoo.2, unless I also need to link with libbar.1? If so, do I need to specify this requirement to the linker? Curious, Martin