From owner-freebsd-hackers Sat Mar 2 00:44:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA19981 for hackers-outgoing; Sat, 2 Mar 1996 00:44:10 -0800 (PST) Received: from DeepCore.dk (aalb11.pip.dknet.dk [194.192.0.171]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id AAA19920 for ; Sat, 2 Mar 1996 00:43:38 -0800 (PST) Received: (from sos@localhost) by DeepCore.dk (8.7.4/8.7.3) id JAA20533; Sat, 2 Mar 1996 09:28:10 +0100 (MET) Message-Id: <199603020828.JAA20533@DeepCore.dk> Subject: Re: Linux "stub" libraries? (was Re: Quake's out..) To: jehamby@lightside.com (Jake Hamby) Date: Sat, 2 Mar 1996 09:28:10 +0100 (MET) Cc: hackers@freebsd.org (FreeBSD hackers) In-Reply-To: from "Jake Hamby" at Mar 1, 96 07:11:02 pm From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk In reply to Jake Hamby who wrote: > > On Fri, 1 Mar 1996, Stefan Esser wrote: > > > Exactly. And those will take away precious RAM pages in my system, > > for identical functionality as provided by the FreeBSD libraries. > > (And it may amount to several MB total, if native and Linux X11 > > binaries are used simultanously ...) > > > > It's the same situation, that causes Linux to need more RAM, if both > > a.out and ELF applications are used. But we always managed to avoid > > this ... > > Well, the ultimate solution would be to somehow make "stub" versions of > all the Linux shared libraries (a.out and eventually ELF) that simply > connect and "pass through" to the FreeBSD version. Can anybody with > experience in the technical issues verify whether or not this is possible? > If so it would be a great boost for us (and could be applied to Linux for > systems with a.out and ELF binaries). Hmm, I think it might be possible to fake ALL the libs under ELF, the way it works we should be able to make our own linuxELF libs and have them working WITHOUT even a kernel emulator. THis way I can run (some) SVR4 binaries on my system, with a fake svr4 libc that provides the svr4 functionality but have a freebsd system call interface. This greatly depends on having the source for the libraries, but for the linux case this is no problem (it is for svr4 :( ) The main showstopper here is the amount of work involved in doing this. For svr4 its a "doit once" affair, but for linux you'll have to follow their "patch of the hour" releases to be sure it works, not my idea of having a good time :( > > Well, there won't be FreeBSD support then, because it is too expensive > > for the vendor to support another platform. > > As I said, better to support FreeBSD through emulation than no FreeBSD > support at all. Besides, we should think positively, maybe one day we > will be more popular than Linux and Linux users will have to run FreeBSD > apps in emulation mode. :-) We will have Linux ELF support in FreeBSD, infact we are working on it.. And no, I dont ship "alpha" releases out the door yet :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end ..