On Friday 11 January 2008, Mike Frysinger wrote:
> On Friday 11 January 2008, H. Peter Anvin wrote:
> > Again, I don't particularly care about what they're named, but the whole
> > point is
> >
> > #include
> >
> > if you want the subset and
> >
> > #include
> >
> > if you want the whole
On Friday 11 January 2008, H. Peter Anvin wrote:
> Mike Frysinger wrote:
> >> all this stuff is ABI constants, and the only reason glibc
> >> doesn't use them is that glibc prefers to use enums over #defines.
> >
> > a proper libc defines things in their headers according to the POSIX
> > specs rat
Mike Frysinger wrote:
all this stuff is ABI constants, and the only reason glibc
doesn't use them is that glibc prefers to use enums over #defines.
a proper libc defines things in their headers according to the POSIX specs
rather than relying on others to do it for them. if you want to argue
On Friday 11 January 2008, H. Peter Anvin wrote:
> Mike Frysinger wrote:
> > oh, sorry, i see what you mean. i was thinking in terms of crap removed
> > (as that's what i'm after), not crap added (which is what Peter is
> > after). i hadnt noticed that. i dont know if it'll break glibc (and
> >
H. Peter Anvin wrote:
Right now, glibc is special-cased. glibc also tends to be very
deliberate about its kernel header inclusions. It wants a subset of the
available defines, so it can include a subset header.
The reverse is definitely possible too -- all other users (kernel,
newlib, die
Mike Frysinger wrote:
oh, sorry, i see what you mean. i was thinking in terms of crap removed (as
that's what i'm after), not crap added (which is what Peter is after). i
hadnt noticed that. i dont know if it'll break glibc (and really, any other
sane libc). if that is the case, then i thin
On Friday 11 January 2008, David Miller wrote:
> From: Mike Frysinger <[EMAIL PROTECTED]>
> Date: Fri, 11 Jan 2008 01:23:37 -0500
>
> > On Friday 11 January 2008, David Miller wrote:
> > > From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> > >
> > > > Seems the most logical thing to do would be to break
David Miller wrote:
Hmmm...
Doesn't glibc include linux/socket.h? If so, before it wouldn't get
the sa_family_t et al. defines (because __GLIBC__ will be defined and
it will be >= 2), but with your change it get those things.
Correct me if I'm wrong.
At the moment, yes, it does.
-
From: Mike Frysinger <[EMAIL PROTECTED]>
Date: Fri, 11 Jan 2008 01:23:37 -0500
> On Friday 11 January 2008, David Miller wrote:
> > From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> > > Seems the most logical thing to do would be to break out the small
> > > portion that everyone wants into or somesuc
Mike Frysinger wrote:
On Friday 11 January 2008, David Miller wrote:
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Seems the most logical thing to do would be to break out the small
portion that everyone wants into or somesuch, and
then remove those ifdefs entirely.
Proposed patch (still being t
On Friday 11 January 2008, David Miller wrote:
> From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> > Seems the most logical thing to do would be to break out the small
> > portion that everyone wants into or somesuch, and
> > then remove those ifdefs entirely.
> >
> > Proposed patch (still being tested
From: "H. Peter Anvin" <[EMAIL PROTECTED]>
Date: Wed, 02 Jan 2008 10:09:56 -0800
> Seems the most logical thing to do would be to break out the small
> portion that everyone wants into or somesuch, and
> then remove those ifdefs entirely.
>
> Proposed patch (still being tested) attached...
I
Mike Frysinger wrote:
On Tuesday 01 January 2008, H. Peter Anvin wrote:
Mike Frysinger wrote:
The kernel __GLIBC__ hacks were re-added so as to appease klibc people,
but the klibc people didnt actually fix the problem on their side. This
patch imports the structures/defines that klibc seems to
13 matches
Mail list logo
