You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue or Feature Request:
I'd like to include the glibc libraries and headers in the SDK, as we already do for musl.
It's still desirable to ship glibc as packaged by the core kit, for ease of patching and because of some complexities involved in creating the final build (such as dealing with locales).
However, providing a copy of glibc in the SDK's sys-roots will make it easier to move various packages out of the core kit. This is especially true for Go and Rust programs, which rarely need anything beyond the C library to build. It also helps with packages like libkcapi, which would ideally go along when the kernels move to a separate kit.
This relies a lot on glibc's backwards compatibility, and on making sure the SDK's version of glibc never gets ahead of the core kit's.
Alternatives:
Twoliter supports kits that depend on other kits, so we could just make everything depend on the core kit. This wouldn't help for libkcapi, and it would be overkill for kits that only needed the glibc dependency.
We could also have a libc kit. In practice, that would take us from the current world where all kits have to be updated whenever the SDK changes, to a world where all kits have to take a combined SDK and libc kit update. Keeping the two together is appealing in the absence of fully automated updates everywhere.
Also, there's overhead and inefficiency that arises from making changes that touch multiple kits. I'd like to stick with larger building blocks for now: kits for "all kernels" and "all of userspace" are OK, but kits for one library are not.
The text was updated successfully, but these errors were encountered:
Image I'm using:
v0.47.0
Issue or Feature Request:
I'd like to include the glibc libraries and headers in the SDK, as we already do for musl.
It's still desirable to ship glibc as packaged by the core kit, for ease of patching and because of some complexities involved in creating the final build (such as dealing with locales).
However, providing a copy of glibc in the SDK's sys-roots will make it easier to move various packages out of the core kit. This is especially true for Go and Rust programs, which rarely need anything beyond the C library to build. It also helps with packages like
libkcapi
, which would ideally go along when the kernels move to a separate kit.This relies a lot on glibc's backwards compatibility, and on making sure the SDK's version of glibc never gets ahead of the core kit's.
Alternatives:
Twoliter supports kits that depend on other kits, so we could just make everything depend on the core kit. This wouldn't help for
libkcapi
, and it would be overkill for kits that only needed the glibc dependency.We could also have a libc kit. In practice, that would take us from the current world where all kits have to be updated whenever the SDK changes, to a world where all kits have to take a combined SDK and libc kit update. Keeping the two together is appealing in the absence of fully automated updates everywhere.
Also, there's overhead and inefficiency that arises from making changes that touch multiple kits. I'd like to stick with larger building blocks for now: kits for "all kernels" and "all of userspace" are OK, but kits for one library are not.
The text was updated successfully, but these errors were encountered: