Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!psgrain!news.uoregon.edu!news.dacom.co.kr!usenet.seri.re.kr!news.cais.net!news.jsums.edu!gatech!news.mathworks.com!fu-berlin.de!cs.tu-berlin.de!informatik.uni-bremen.de!nordwest.pop.de!uniol!uni-erlangen.de!news.tu-chemnitz.de!irz401!uriah.heep!news From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: FreeBSD vs Linux Date: 6 Apr 1996 00:04:58 GMT Organization: Private BSD site, Dresden Lines: 117 Message-ID: <4k4cfa$ava@uriah.heep.sax.de> References: <4issad$h1o@nadine.teleport.com> <Pine.PMDF.3.91.960324150948.9390A-100000@plains.uwyo.edu> <4jejjt$cdb@park.uvsc.edu> <315E0F1A.4E3FB53D@lucon.org> <Pine.LNX.3.91.960401105810.31921A-100000@gallup.cia-g.com> <4jso8v$n5i@dyson.iquest.net> <31642098.75AB4317@gnu.ai.mit.edu> <4k2cvc$j8e@park.uvsc.edu> <31657509.5E45C160@gnu.ai.mit.edu> Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) NNTP-Posting-Host: localhost.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: knews 0.9.3 Cc: peter@freebsd.org "H.J. Lu" <hjl@gnu.ai.mit.edu> writes: I normally tend to ignore these religous wars... > Assume you have to switch to ELF, why not now? We are not ready for it. We haven't decided for a good strategy on how to do it without causing too much friction. We aren't in time- pressure either, and there are apparently quite more important things to work on. > It will make commercial software vendors easier to write softwares > for you. That's a claim you cannot proof, however. ELF won't make writing application software easier. (With the minor potential exception of C++ *libraries*.) Actually, people won't really notice the under- lying object format at all, if we'll do the transition right. Shared libraries are being created with cc(1) or ld(1), and there ain't a need for any obvious change in the user interface. > Ask your FreeBSD/ELF gurus for why ELF is better than a.out > and what it can do for you and a.out cannot. Here are some parts of a message posted by Peter Wemm to the FreeBSD-core mailing list some time ago. I'm posting this without his explicit permission, but the opinions mostly agree with mine, and haven't caused major objections in the FreeBSD-core mailing list either. (I'm Cc'ing Peter so he could jump in if i've got something wrong.) I think this is a good summarize for why one should chose ELF in the future, but also for why the change doesn't need to happen *right now*. ~From: peter@freebsd.org (Peter Wemm) ~To: core@freebsd.org ~Subject: .. uhh.. ELF... ~Date: Sun, 17 Mar 1996 03:10:37 +0800 I should know better than to stir up a religous argument, but I was fiddling with this again today, and I got to thinking about where we're going.. First, a couple of points that I think are reasonably agreed on: 1) Our dynamic linking system is based on the Sun one, with some warts fixed (eg: no .sa files). 2) ELF is a superset of the Sun a.out rtld system.. 3) At this present time, our system and ELF are approximately comparable feature-wise. 4) Our build-tools have diverged so far from the gnu baselines, that they are "our problem now". 5) Our gas and ld (both of which are based on a pre-release code, about version 1.92.mumble) have a lot of "minor, annoying, problems" (check comments in .s files about this, as well as the number of times instructions are manually assembled with .byte instructions because ``gas fucks up''). Nobody seems particularly interested in finding and fixing the bugs, missing instructions, etc, as there are better things to do.) 6) the Linux camp is *very* actively developing ELF support, the tools, compilers, etc. They are already able to convert old static libs to/from a.out/elf format. 7) ELF is currently a buzzword, and a must-have "feature list" item. As I understand it, the gcc-2.7 implementation of g++ *uses* weak symbols in it's virtual imheritance tables, exception support, etc, and it doesn't quite work right without weak symbol support.. (most of the time it's OK, but you can get code which wont link due because of inheritance). ie: it can be configured to not use .weak (which we dont have), but it's less functional. Also, ELF has a section for comments, so all the ``char rcsid[] = "$Id$"'' stuff goes into it's own section and does not take up text space. You are able to strip them out, in much the same way that 'strip' takes out debug symbols. There are "text", "rotext" and "data". No longer do strings and other read-only data have to go in the text section, they have their own read-only section. [...] There's some other interesting possibilities in the future.. ELF is, by it's very nature, Extensible. Features can be added to support other languages etc. C++ is one that is most likely going to demand more support, because the constructor and inheritance tables are getting more and more perverse. ELF is very suited to things like linker sets, only it can be implemented with much more flexability. [...] Not to mention what it could do for a kernel.. There could be pageable sections, there could be tags on data for global symbols versus per-cpu symbols in a SMP system (eg: IdlePTD, which is different on each CPU). We could even have horrible things like a paged kernel symbol table to support a real in-kernel linker for on-demand LKM's, etc. No problem for a section for a variable sized MFS incore boot-image - it would no longer be necessary to reserve a "hole" bigger than the intended MFS filesystem and splice it in, space could be allocated *after* the kernel and MFS image was built. Making releases would be a lot easier.. :-) Also, there's the ability to have a static executable that uses no shared libraries, ld.so, etc, but still has the ability to do runtime loading of shared objects when linked with -ldl. (This has been asked for several times on the lists that I've noticed) Anyway, I'll get to the point of all this waffle... Right at this very moment, I dont think there's a compelling reason to go to ELF. It's probably not going to be compelling for some time. [...] -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)