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
Roman Zippel wrote:

>> The way libgcc is handled inside gcc is, indeed, completely screwed up; even
>> the gcc people admit that. They pretty much don't have a way to handle the
>> effects of compiler options on libgcc, especially the ones that affect binary
>> compatibility.
>
> Nobody said it's perfect. Especially the last point speaks against
> multiple versions of the same library, as it makes it hard to mix
> binaries/libraries. With a single kinit binary it's not really a problem
> yet, but will it stay this way?

What on earth are you talking about?

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.

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.

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

-hpa
-
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 01:56    [W:1.903 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site