feat(25.04): libc6-dev slices

[lczyk]

Proposed changes

A bunch of other PRs (see below) depend on this, and it's a bit tricky slice. This PR cherrypicks the libc6-dev SDF in order to make other PRs smaller.

Related issues/PRs

This PR is a member of a chain of PRs which depend on one another. The first commit is a squashed version of everything below it. Please review the 'root' PRs first.

#633 - ROCKS-2270/libc6-dev-for-25.04 (this PR)
└ #644 - ROCKS-2270/binutils-for-25.04
....└ #648 - ROCKS-2270/cpp-for-25.04
........└ #649 - ROCKS-2270/gcc-14-for-25.04
............└ #610 - ROCKS-2271/rust-1.84-25.04
................└ #634 - ROCKS-2271/cargo-1.84-25.04

Cherrypicked from #610, #598

Forward porting

#664

Checklist

• I have read the contributing guidelines
• I have tested my changes (see how)
• I have already submitted the CLA form

[github-actions]

Diff of dependencies:

slices/libc6-dev.yaml

@@ -1,5 +1,3 @@
-libc-dev-bin
 libc6
 libcrypt-dev
 linux-libc-dev
-rpcsvc-proto

---

[lczyk]

• libc-dev-bin dep is not included since it only provides the gencat utility which can be installed separately
• rpcsvc-proto dep is not included since it only provides rpcgen utility which can be installed separately. it also has a bunch of header files, none of which are included by the headers in libc6-dev

[Copilot]

Pull Request Overview

This PR introduces slice definitions for three C library development packages essential for building C/C++ applications on Ubuntu 25.04. The slices define how to package header files, static libraries, and shared library symlinks for development purposes.

• Adds linux-libc-dev slices for Linux kernel header files including ASM headers
• Adds libcrypt-dev slices for cryptographic library development components
• Adds comprehensive libc6-dev slices for the core GNU C library development files

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
slices/linux-libc-dev.yaml	Defines slices for Linux kernel headers (asm-headers, linux-headers) and copyright
slices/libcrypt-dev.yaml	Defines slices for cryptographic library headers, static libs, and symlinks
slices/libc6-dev.yaml	Defines comprehensive slices for GNU C library development including headers, static libs, audit tools, and symlinks

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[lczyk]

added priority since its related to a lot of active PRs and would help a lot with pushing them forward

[zhijie-yang]

Thanks for the PR. Here are some points we can talk about.

[clay-lake]

Few minor questions below but otherwise LGTM

[lczyk]

based on the overall consensus i've renamed the posix-libs slice to core and i've added it as essential for libutil, librt etc. ( good spot @cjdcordeiro ) some of the tests for the behavior there will need to come in #644 since we don't have the linker yet, and using the host linker (from outside of the chroot) for test would be tricky and error-prone imo. will work on that now and add these to #644, as well as updating it to use the new slice names.

core slice represents the libraries one will always need, since they are the basic things you need to create a binary. the tests should check that + check that, for example, if we install the libm slice but then manually delete core, we cannot compile a working binary -- aka test asserting / showing that core libs are indeed core.

[lczyk]

based on dpkg --search on a full installation of ubuntu 25.04 (find -maxdepth 1 -type f -printf "$PWD/%P\n" | xargs -n1 dpkg --search) i found that it seems to be safe to glob bits and src. i've globbed these, but left arch-specific globs explicitly specified. i also left all shallower things unglobbed.

its possible that /usr/include/net or /usr/include/netinet could be globbed too, but the savings there are much smaller.

[lczyk]

just so it does not get lost in a response to the review comment, here is the data dump of dpkg -c of libc6-dev .h files in all supported archs.

[lczyk]

nevermind. i thought for a bit more about what i'm doing and turns out we would conflict (and not in a trivially resolvable way, like with some more subpaths i don't think):

$ apt-file search --regexp '^/usr/include/.*-linux-.*/bits/.*.h' | sed -e 's/: .*//' | sort -u
libc6-dev
libstdc++-11-dev
libstdc++-12-dev
libstdc++-13-dev
libstdc++-14-dev
libstdc++-15-dev
musl-dev

$ apt-file search --regexp '^/usr/include/.*-linux-.*/sys/.*.h' | sed -e 's/: .*//' | sort -u
libbsd-dev
libc6-dev
musl-dev
systemtap-sdt-dev

reverted back to full unglob. i guess we are swallowing the full diff..

given that, i will echo one of the points from @zhijie-yang: full listing is fine and all, but this puts even more importance on slice coverage tooling. luckily its an item on my board for next week. it was meant to be ;)

[lczyk]

also, just for the sake of it i've done apt-file search --regexp '^/usr/include/[^/]*.h' | sed -e 's/: .*//' | sort -u | wc -l and its 2190 packages which would conflict on /usr/include. well, 2119 since libc6-dev is one of them

[lczyk]

another discovery which, actually, simplifies slicing quite a lot: there is a bunch of libraries which are just dummy empty archives. the actual functionality has been merged into libc6, and the files are there just to enable -l flags for backwards compatibility. This is the case for libanl.a, libdl.a, libg.a, libpthread.a, libpthread_nonshared.a, librt.a and libutil.a. hence tey can be included in the core slice "for free" since they don't bloat the filesystem and don't include any functionality -- have no possible CVEs (unless someone finds a way to exploit 3c21 7261 6863 0a3e -- the ar archive file header, which is literally all there is in these files).

i've simplifies the slices accordingly.

P.S.: i did make sure that all of the above libs are indeed empty on all supported architectures.

[zhijie-yang]

Thanks for the work. A nitpick on stab.def

[alesancor1]

This is amazing work, seems you got to understand libc6 quite in depth, which is great! (some bits are a bit over explained in comments I'd say, but not against it)

Apart from what others said I have no further comments, LGTM! Let's get those nits fixed quick and we good to go on my end 👍

[zhijie-yang]

Looks good to me now! Many thanks!

[clay-lake]

Nice work 💪