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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
