OK, I've had a number of people asking me about versioning wrt to glibc.
So I am going to add something similar to the following into my
FAQ/README/whatever documentation. I would appreciate any comments on my
description of the differences/what it is.
Does it make sense? (Consider you are a new comer to ARM Linux)
Is it correct?
Anything missing?
Is it too long/short?
Thank you,
-Rms
Rod m. Stewart <[EMAIL PROTECTED]>
-----------------
Q: What is the difference between a versioned glibc and a non versioned
glibc on ARM Linux systems?
A: In the beginning there was ARM Linux, this was originally based on libc 4.
Then work began on what was to become Glibc 2.1 (also sometimes referred to
as libc 6). Glibc 2.1 brought a number of new enhancements and bug fixes
to the field. This was seen as being a good thing (tm?), hackers around
the world cheered.
One of the new features of Glibc 2.1 was symbol versioning. Symbol
versioning is seen as a good thing, but there were originally a few
problems, which have led to the confusion of today. The following is an
excerpt from the Glibc FAQ which is a short description of symbol versioning
and why you you might want to use it.
1.17. What is symbol versioning good for? Do I need it?
{AJ} Symbol versioning solves problems that are related to
interface changes. One version of an interface might have been
introduced in a previous version of the GNU C library but the
interface or the semantics of the function has been changed in
the meantime. For binary compatibility with the old library, a
newer library needs to still have the old interface for old
programs. On the other hand, new programs should use the new
interface. Symbol versioning is the solution for this problem.
The GNU libc version 2.1 uses symbol versioning by default if
the installed binutils supports it.
We don't advise building without symbol versioning, since you
lose binary compatibility - forever! The binary compatibility
you lose is not only against the previous version of the GNU
libc (version 2.0) but also against all future versions.
Now you ask: If versioning is such a great thing, then why would anyone
not use it? Essentially it amounts to how the software world works.
[Once you release something, people get really angry if you try to break
backwards compatibility with what they currently have. They do not care
if the "fix" is for the better. All they care about is: you broke
backwards compatibility. They might not know what this means, but if you
tell them you are breaking it, they get upset. They do not care if
eventually they will have to do the upgrade, they will fight you until
the last possible moment. Well that is my version of the story :) -Rms]
In the early development for glibc 2.1, binutils was broken with regards
to symbol versioning on ARM Linux. This meant there was no choice but to
build glibc without symbol versioning, a non-versioned system.
As usually happens in a case like this, someone went and released a product,
with a non-versioned glibc. At the time it was the right thing to do,
as it was the only thing which worked then.
There has only been one main ARM Linux distribution which has been released
with a non versioned glibc. This is the current software released from
Rebel.com (originally it was from Corel Computer -->> Hardware Computing
Canada -->> Rebel.com). This is normally referred to has the DM (10, 12,
3.1-15, 15) stuff. These releases target ARMV4L systems (StrongARM, and
others).
There was also a short period of time when there was a non versioned
release of Debian ARM was released, although most memories of it are
now lost in the depths of time. I do not believe it is still around.
How things look today (Early 2000)?
Today things are looking better.
Distributions which use a versioned glibc include: Debian-ARM, and Titan
The only known distribution which uses a non versioned glibc is the current
stuff from Rebel.COM. All current DM releases: 10, 12, 13, 3.1-15, all
current OS releases: 1.0, 1.1. As well as the SD, and anything else
which has been released in the past. Top hackers are working hourly to
fix the problem.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
This is a backup list for [EMAIL PROTECTED], and the subscription
list is regularly synchronised.
