From owner-freebsd-current Thu Mar 14 20:20:23 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA27450 for current-outgoing; Thu, 14 Mar 1996 20:20:23 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA27444 for ; Thu, 14 Mar 1996 20:20:12 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.6.12/8.6.12) with ESMTP id UAA24182; Thu, 14 Mar 1996 20:19:50 -0800 Message-Id: <199603150419.UAA24182@austin.polstra.com> To: andreas@knobel.GUN.de Cc: freebsd-current@freebsd.org Subject: Re: Elfkit-1.0.1 announcement In-Reply-To: Date: Thu, 14 Mar 1996 20:19:50 -0800 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm wrote: > I tried to build up elfkit but had big trouble to compile the > patched libc (2.1.0). If you're not running 2.1.0, then your include files are, of course, wrong for the 2.1.0 library that elfkit uses. You can solve that problem by putting the 2.1.0 /usr/include tree into /usr/local/elf/i386-unknown-freebsdelf/include, instead of creating a symbolic link to the system's include files. I've updated the installation instructions for the next release of elfkit, to explain that. > Are there any newer patches available? Best would be, if one could > use -current's libc, then the header files certainly would fit > better ... Yes, that's the plan, don't worry. We will be tracking -current soon. In fact, I want to merge the ELF changes into -current, so that one set of sources can be used for both a.out and ELF. The existing patches in elfkit-1.0.1 are quite close to that goal already; there's just a little more work to do. Here is why I decided to use the 2.1.0 libc initially: 1. I wanted to distribute the library as a set of patches, so I needed a stable, widely-available base. -Current changes constantly, so it really can't be used as a basis for patches. 2. During initial development of the ELF version of the library, I didn't want to waste a lot of time keeping up with changes in -current. 3. At that time, I didn't have a machine running -current. (Now I do.) The situation is different now, so I will start tracking -current soon in elfkit. > BTW, what about switching totally to elf ?! Then such a hack wouldn't > be necessary in the future. Sssssh! Not so loud! You might freak a bunch of people out! I think we are going to have to switch completely to ELF at some point. The alternative is to become ... irrelevant. Our language tools are currently way behind the curve. Ld has design flaws in its handling of shared libraries, "as" lacks weak symbol support, and our compiler dates back to December, 1994. (That's OK for C, but it loses in a major way for C++.) Try to build the most recent version of binutils or gcc, and you'll find that they don't build or don't work under FreeBSD. Why is that? It's because fewer and fewer developers are interested in a.out any more. Nobody cares enough to keep it supported. > I think ELF is currently _the_ standard. Yep. The adaptations to binutils-2.6 and gcc-2.7.2 that I had to make for elfkit were almost trivial. By contrast, I spent days on end trying to make binutils-2.6 support FreeBSD/a.out before putting it aside in frustration. There is a lot of opposition to the idea of switching to ELF in the FreeBSD camp. Much of it is well-founded. Such a switch would cause big-time disruption for a while. Those of us who would like the change to happen can't expect to get agreement by simply saying, "We should switch to ELF." That's not reasonable. Instead, we must _make ELF work_, and let its advantages speak for themselves. That's why I'm working on elfkit, and why others such as Søren and Peter are working on kernel support. (Well, OK, it's fun, too :-) Stay tuned, John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth