New/gnu.org/glibc#5080
Conversation
dosubot
Bot
added
size:L
|
This fails, but I'm hoping dosu bot has a clue |
|
oh ok, it didn't build successfully for me on my local machine. I'll have to look into that… could be the pkgx docker image doesn't have the pre-reqs installed? That would be an oopsie. Still, nice! It built. Tests fail. Which begs the question: how do you test this? |
right. i think the answer is something like this: pantry/projects/gnu.org/glibc/package.yml Lines 68 to 100 in 7976e91 |
|
k the local build issues are due to us building into macOS mounted volume and the case insensitive filesystem. Which is annoying. What we need I guess is the inverse: everything is in a persistent linux docker volume and somehow we make it mounted locally so you can easily browse it. Or something |
|
Running in a local docker container I can get it all built, actually using it is problematic. The resulting binary we create segfaults in some of the glibc runtime code that starts the executable. Tracing it with ChatGPT I ended up trying to run |
-pie in LDFLAGS leaks into glibc's static auxiliary tool builds
(support/test-run-command etc.) and breaks them with:
hidden symbol \`_DYNAMIC' isn't defined
glibc decides its own pie/-shared per target — passing LDFLAGS=-pie
is harmful here even though it was in pkgxdev#5080's draft.
CI link:
https://github.com/pkgxdev/pantry/actions/runs/26157895410
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
For most projects, adding `${prefix}/lib/` to `LD_LIBRARY_PATH` /
`LIBRARY_PATH` is exactly what you want: subsequent commands in the
pkgx env find the bottle's shared libraries.
For projects that *ship libc itself* (gnu.org/glibc; musl bottles
when they land) the auto-export is harmful: every executable in the
env tries to load the bottle's libc.so.6, but the host's own
ld-linux is the one doing the loading. When the bottle's libc is
newer than what the host's ld-linux supports, every command in the
env breaks:
mkdir: /lib/ld-linux-aarch64.so.1: version `GLIBC_2.35' not found
(required by /opt/gnu.org/glibc/v2.43.0/lib/libc.so.6)
Add a small hardcoded `NO_LIB_EXPORT` set listing projects whose
`lib/` and `include/` must NOT be auto-added. For these projects,
LIBRARY_PATH / LD_LIBRARY_PATH (set later from LIBRARY_PATH) and
CPATH all skip the bottle. Consumers that explicitly want to link
against this glibc bottle do so via a sysroot route (`-B`, `-isystem`,
`-Wl,--dynamic-linker=…`), not via env auto-population.
This is the v1 implementation; the set is intentionally minimal and
hardcoded. v2 should express the opt-out in the bottle's own metadata
so the pantry can add new libc-style bottles without a coordinated
libpkgx release.
Refs:
- pkgxdev/pantry#12968 (gnu.org/glibc PR) — the use case. The PR
currently works around this by installing libs under lib/glibc-X.Y/
to keep the top lib/ free of libc.so.6. With this libpkgx change,
glibc can ship libs at the conventional lib/ path.
- pkgxdev/pantry#5080 (mxcl's Feb 2024 glibc attempt — same root cause).
Includes a regression test that asserts gnu.org/glibc's lib/ is NOT
exported while curl.se's lib/ still is (current behaviour preserved).
2 participants
My attempt at #147