lkml.org 
[lkml]   [2006]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [klibc 07/31] i386 support for klibc
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-30 02:26    [W:0.068 / U:1.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site