Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

include glibc headers and libraries in SDK #221

Closed
bcressey opened this issue Nov 14, 2024 · 0 comments · Fixed by #222
Closed

include glibc headers and libraries in SDK #221

bcressey opened this issue Nov 14, 2024 · 0 comments · Fixed by #222
Assignees

Comments

@bcressey
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant