lkml.org 
[lkml]   [1997]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: glibc 2, Linux 2.x and the world of many patches!
On Jul 31, Michael K. Johnson wrote
> I know this isn't related to kernel development, so I'll keep it short,
> but if anyone is looking for glibc patches, you can check our sources.
> The patches for glibc (where needed) are generally called something
> like <foo>-glibc.patch, so you shouldn't need to look very hard to find
> them.

While your sources are a good place to start---and as the lead in the
Debian port to the AXP, I've looked at an awful lot of them---there
are a couple of places where they're less-than-useful for people not
using RedHat (which is not intended as a criticism---just a statement
of fact).

First, your current patches aren't against the current glibc, which
means they do not actually take care of many of the issues one can
find in compiling against glibc (for instance, at least on the alpha,
the size_t vs. int on socket functions issue that was introduced after
the snapshot you use---I suspect this would show up on UltraPenguin,
too).

Second, your patches aren't as useful if one wants to be able to use
the same source to build for multiple architectures, as they're not
usually #ifdef'd appropriately (because you're packaging system
handles it).

Third, in order to get at the patches, one has to download the entire
source package, which is unfortunate in the case of gcc or gdb or
xemacs and the like.

But, yes, I often look at your patches when preparing to port a new
package, and I appreciate the work you guys have put into collecting
all the alpha/glibc stuff.

Mike.
--
Don't touch that! It's the History Eraser Button

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.060 / U:1.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site