[klibc] [klibc 07/31] i386 support for klibc
zippel at linux-m68k.org
Thu Jun 29 17:23:23 PDT 2006
On Thu, 29 Jun 2006, H. Peter Anvin wrote:
> a. The semantics of these functions are well-defined, stable, and documented
> in the gcc documentation. It's not like they have compiler-version-specific
> definitions that could change.
It's documented in the internals section for gcc's own purposes. This
doesn't make it a public API.
> b. For static binaries, this is no issue. klibc is shared, not dynamic (thus
> eliminating the need for a space-consuming dynamic linker), but it also means
> that there is no cross-version calling; each build of the shared klibc library
> has a hashed filename, thus allowing multiple versions of klibc to coexist if
> absolutely necessary.
> Either way, this is a red herring.
Since you don't explain your plans, it's hard to tell.
> > > > The standard libgcc may not be as small as you like, but it still should
> > > > be
> > > > the first choice. If there is a problem with it, the gcc people do
> > > > accept
> > > > patches.
> > > That's just an asinine statement. Under that logic we should just forget
> > > about the kernel and go hack the gcc bugs du jour; we certainly have
> > > enough
> > > workarounds for gcc bugs in the kernel.
> > Sorry, but I can't follow this logic.
> I'm not entirely surprised.
So instead of arguments you try it now with insults... :-(
More information about the klibc