Date: Thu, 14 Mar 1996 20:19:50 -0800 From: John Polstra <jdp@polstra.com> To: andreas@knobel.GUN.de Cc: freebsd-current@freebsd.org Subject: Re: Elfkit-1.0.1 announcement Message-ID: <199603150419.UAA24182@austin.polstra.com> In-Reply-To: <Pine.BSF.3.91.960314222128.2003A-100000@knobel.gun.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603150419.UAA24182>