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 [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]
