Messages in this thread | | | Date | Fri, 30 Jun 2006 02:23:23 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: [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/
| |