David Douthitt wrote:
>Pim van Riezen wrote:
>
>>On Wed, 16 May 2001, David Douthitt wrote:
>>
>>>I must say.... I've been surprised at all the excitement over Linux
>>>2.4. I've noticed that all of you kernel wizards are scrambling to
>>>get Linux 2.4 installed on LRP, while glibc 2.1 gets ignored.
>>>
>>For me, it's basically the fact that I'm silently still pissed off with
>>the mess I, as a developer, get when dealing with different glibc
>>versions. No matter what glibc I use on my development system, at the end
>>if I want to produce binaries I'll have to use three different
>>environments if I want to cater for all glibc variations. Now that
>>RH7/glibc2.2 is gaining acceptance that'll be four:
>>
>> libc5
>>
Is anyone still using this?
>>
>> glibc2.0
>> glibc2.1
>> glibc2.2
>>
I may be wrong, but I think that anything using ipv6 won't compile with
glibc 2.0. I'm not an expert on this matter but I thought that with
symbol versioning applications compiled with glibc 2.0 should run on
glibc > 2.0 systems.
>
>Sounds like a good reason to shift from using glibc 2.0 to using glibc
>2.1 or 2.2.
>
I'd vote for 2.2. It may be bigger, but 2.1 will be unmaintained rather
soon I'm afraid. So when we choose for glibc 2.1 we might end up with
the same mess as we have for glibc 2.0 now in a year or so. Unless one
of us is capable of backporting security fixes 2.2 is the way to go I
think.
>I, too, have seen teh MESS that comes from trying to
>compile things for glibc 2.0. In particular, there are several
>applications which don't seem like they'll compile under glibc 2.0:
>
>* ax25-tools
>* zebra
>* brctl
>
>Of course, they all compile WITHOUT ERRORS OR WARNINGS under glibc
>2.1.
>
>>If you add to that the fact that a typical embedded application shouldn't
>>be using much more than the stdio, string and socket functions and you see
>>that I'm reluctant to change over to a newer glibc, which will probably
>>take more space without offering much in exchange.
>>
That makes me wonder if anyone has seriously considered uClibc. It
probably has some limitations. One is of course that binaries compiled
with glibc won't run on a uClibc system. I've been playing with uClibc
lately and there seems to be considerable progress in it's development.
With the last snapshot I tried also the libdl seemed to work, which
makes it usable for an LRP like distro.
Also in this article:
http://embedded.linuxjournal.com/magazine/issue00/4335/ Bruce Perens
mentions a way of stripping down libraries. May be interesting for us.
>
>How about not having to compile for the old glibc versions? Sounds
>like a good reason to me. You gave lots of good reasons for why LRP
>(and variants) should move to glibc 2.1 or 2.2, instead of arguing
>against it.
>
Ewald Wasscher
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
