Re: glibc / linux fd_set collision
Snow Cat (snowcat@netgate.net)
Fri, 4 Apr 1997 09:47:53 -0800 (PST)
David Holland once wrote:
>
> > > struct stat? I know there are other problems there, but if you ignore
> > > the executable-to-shared-libc problem and just look at the
> > > user-to-kernel problem, it would behave exactly as I described:
> > > [...]
> > > If, however, the application and kernel shared the header for the stat
> > > structure, all four cases would compile and run.
> >
> > A library is always build with a certain library as the basis. Your
> > examples are not valid since there are internal uses of the stat
> > structure in the libc.
>
> I wasn't concerning myself with shared library issues when making that
> argument. I know it gets worse.
>
> > Beside, I don't understand why this discussion comes up again. Linus
> > wants separate kernel<->libc headers since he does not want to pay
> > that much attention for user-level compatibility, distribution
> > providers want the two sets (as Debian already does this for libc5)
> > and I certainly also like this since I cannot be hit from a place I
> > hva no influence on (namely the kernel).
>
If this is the case, we may need to keep a separare library that
provides ONLY direct access to Linux system calls (and a bit more
friendly than syscallN()). Linux glibc can be built on top of this
library and users of bleeding-edge features can build with
-I/usr/include/linux -llinux until they are incorporated in glibc.
--
_. _ .
(_ ,_ _ , . / ` _ _L | Email: Oleg Kibirev <snowcat@netgate.net>
._)| U(_)\/\/ \_,(_L/L | http://ng.netgate.net/~snowcat/
------------------------'