Date: Mon, 11 Mar 1996 13:59:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: sos@freebsd.org Cc: langfod@dihelix.com, current@freebsd.org Subject: Re: Native & Linux ELF support finally there... Message-ID: <199603112059.NAA03889@phaeton.artisoft.com> In-Reply-To: <199603110842.JAA18791@ra.dkuug.dk> from "sos@freebsd.org" at Mar 11, 96 09:42:15 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Now a side note: for those of us with our heads in the closet are there > > any pointers to the wonders of why Elf exists? i.e. what makes it > > so great that I should bow down before it? > > For FreeBSD bins ? nothing as fas as I can tell, It helped Linux > clean up their shared libs mess, we did that right in the first place :) It buys us the ability to segregate code based on ELF segment ID's (COFF gives us the same thing). The main wins are in a kernel arena: we can reclaim memory for unused drivers, and we can load/unload drivers on the basis of designating them as "fallback". That is, I could have a default console driver, load a replacement, and reclaim the space used by the default even though it was statically linked into a generic kernel. For applications with shared libraries, the current scheme has the text dynamically linked, but the data statically linked into the library. Because of this, it is questionable whether BSD shared libraries, or pre-ELF Linux shared libraries, can be used to meet the relink clause of the LGPL. That is, a library change that did not change interface could still change internal data and usage of data (the bind/sendmail "shared library" change about 5 months ago was exactly this kind of change), and thus make it impossible to link a binary shared and still comply with LGPL without shipping your object modules around with your binary. I think if you really pressed, it, the changed for i18n would render a large number of a.out Linux apps liked shared in violation of the LGPL relink clause because of the sys_errlist reference changes. > (who was it that said think first then act :) That would be me. ;-)... at least, I think it was largely my posts (and loud, obnoxious argument) that prevented rolling in the SVR3 style shared libraries when they were still the only thing available. > Besides that there are a lot of possibilities in ELF like multible > text segments, specific debugging info etc etc. But none of > that gives us anything in the short run. > I see no immediate need for us to convert to ELF format, but it gives > us some interesting possibilities to be able to run them... The LGPL argument is a good "short run" argument. The kernel arguments are a good "long run" argument, as is common ABI for SVR4 (well, and Linux, I guess) systems. Specifically, there are a hell of a lot of commercial apps that run on UnixWare and x86 Solaris that don't run on Linux or BSDI or NetBSD and don't run under IBCS2 because they are SVR4 binaries, not SVR3. It is also a lot easier to use the Motorolla publication of the SVR4 EABI to implement SVR4/Solaris compatible cshared libraries (for instance, the Linux ABI kludge of including the Linux libs won't work if the liubs are licensed materials -- like those in SVR4 and Solaris). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603112059.NAA03889>