Date: Fri, 14 Aug 1998 06:39:25 +0800 From: Peter Wemm <peter@netplex.com.au> To: Alex <garbanzo@hooked.net> Cc: "Daniel O'Connor" <doconnor@gsoft.com.au>, nik@iii.co.uk, Amancio Hasty <hasty@rah.star-gate.com>, "Jordan K. Hubbard" <jkh@time.cdrom.com>, Joseph Koshy <jkoshy@FreeBSD.ORG>, committers@FreeBSD.ORG Subject: Re: 3.0 Schedule, ELF and CAM Message-ID: <199808132239.GAA17368@spinner.netplex.com.au> In-Reply-To: Your message of "Thu, 13 Aug 1998 14:57:36 MST." <Pine.BSF.4.00.9808131456070.249-100000@zippy.dyn.ml.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alex wrote: > On Wed, 12 Aug 1998, Daniel O'Connor wrote: > > > > one is the current default on the system. > > > This is probably a frighteningly bad idea, but every time I've mentioned > > > it on -hackers or -current, no one's stood up to say so. > > That's a bit limiting.. > > Since you can use both types of libs, why limit youself? > > I would think that in most cases ldconfig /usr/lib/<format of choice> > > would be a better solution. > > What I noticed when I first started messing with Debian was that the > compiler was setup as if it was a cross compiler by default, meaning that > /usr/lib was IIRC, a link to /usr/i386-gnu-linux or something similar. > Why not do something like this? It seems a bit easier to manage, no need > to create special names or anything. > - alex I'd hate to spoil the fun, but there's a couple of issues to keep in mind. - we are using the same compiler front and back ends to generate code for the a.out or elf tools. At the assembler level, things are very close but there is enough to break things if the differences are not taken care of. To use the same compiler, the front end driver has to be taught about tool locations, library paths etc. - the search rules are: In elf mode, we look for an "elf" subdir first, then without it. In a.out mode, we look in an "aout" subdir first if it exists and fall back if not. This means, that if you create a /usr/lib/elf/ then all the tools will happily oblige and use it. - However, keep in mind the big picture.. We must not allow a protracted "fragmented" binary format universe, at least for the core OS. One of the primary reasons for changing is that we can really benefit from the more advanced features, and we could really do with cleaning up all the crud, hacks and workarounds for the old toolset braindamage. Check the assembler source for some really perverse workarounds to get around old gas bugs/limitations. - It's desirable that a -current system can generate a.out binaries for running on older systems. Exactly how much support for this we can do is a matter of debate. Some want to ship 2.2.x libraries as a 'compat' module with 3.0. It's not clear that the 3.0 sources will be able to generate a.out shared libs that are *compatable* with 2.2.x anyway, so the value of being able to build an a.out library set from src/lib is questionable but probably useful in some ways anyway. - It's essential that a -current system can use a.out .a libraries and preferably .so libraries too. .o files (and hence .a librarties) are ``easy'' to convert to elf, so in the worst case you can take your Motif .a libs and convert them to elf and at least get by. The gnu tools have an objcopy tool that can partly do this, but the gnu a.out support for our shared libraries, module header formats etc is very poor or non-existant. A custom tool is a much safer bet and will generate new libraries in a one-off hit. Converting .o files is essentially a matter of renaming symbols, generating a new equivalent data structures, etc. Converting stabs (debugging, or -g data) is probably not worth it. Converting .so is at least an order of magnitude more tedious as there are potential problems with the PIC offset/jump tables, alignment, symbol hashing etc and a fundamentally different _DYNAMIC structure and methodology. - A unified a.out/elf rtld isn't as useful as we (or I) once thought. A once-only forward converter would do just give the same overall result. 2.2.x and 3.0 are not really binary compatable already and we've been holding back a major version bump for too long already. 3.0 (in a.out) would most likely not be .so compatable with 2.2.x anyway, elf doesn't change that. - ldconfig etc have no parallel in elf. That's strictly an a.out tool. ELF lays out it's shared libs via a different strategy that is not quite as flexible as ldconfig, but is damn fast. - All the tools have a consistant control mechanism for choosing binary format preferences etc. It can be set on a system wide basis and overridden on the fly as needed. Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808132239.GAA17368>