Re: [dev] Evils of glibc

2010-10-07 Thread Jacob Todd
Dietlibc is the first thing that came off the top of my head, I have no idea how well it is or if it's maintained. There's no reason not to use uclibc.

Re: [dev] Evils of glibc

2010-10-07 Thread Moritz Wilhelmy
Excerpts from Jacob Todd's message of Fri Oct 08 01:24:55 +0200 2010: > Glibc has been like that for a while. Use dietlibc if you want to actually > link statically. I heard from different sources that dietlibc sucks and is not very well-maintained (not sure if those rumours are true though) Why n

Re: [dev] Evils of glibc

2010-10-07 Thread Jacob Todd
Glibc has been like that for a while. Use dietlibc if you want to actually link statically.

Re: [dev] Evils of glibc

2010-10-07 Thread Uriel
On Thu, Oct 7, 2010 at 10:22 PM, pancake wrote: > Thats not new. 9base build isbroken in arch for about a while. Last glibc is > stupid You say it as if the previous glibc's were not stupid, they just somehow managed to make the latest glibc even *more* stupid than it was already, i'm sure they

Re: [dev] Evils of glibc

2010-10-07 Thread pancake
Thats not new. 9base build isbroken in arch for about a while. Last glibc is stupid On 07/10/2010, at 21:52, "John A. Grahor" wrote: > Here's just another example of the evils of glibc. > > I was linking an executable statically on Red Hat Enterprise 5.5 and got this > message: > > warning:

[dev] Evils of glibc

2010-10-07 Thread John A. Grahor
Here's just another example of the evils of glibc. I was linking an executable statically on Red Hat Enterprise 5.5 and got this message: warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking They've