[klibc] [klibc 07/31] i386 support for klibc

[Roman Zippel]

Hi,

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... :-(

bye, Roman