mirror of
https://github.com/gentoo-mirror/gentoo.git
synced 2026-07-29 22:28:08 -07:00
e6dc7912a8
In a fresh musl stage3, I could reproduce the reported "can't resolve libraries to shared libraries: m"
error. In another, older musl chroot, it worked fine.
The difference in the g-ir-scanner invocations between the two was
the good build had `--extra-library=m` and friends, while the bad one used
raw `-lm`. meson's `_gir_has_option` invokes `g-ir-scanner --help` to see
if it supports `--extra-library` or not.
The check was failing with:
ImportError: Error loading shared library libglib-2.0.so.0: No such file or directory (needed by .../scanner.cpython-312-x86_64-linux-musl.so)
because RPATH didn't reflect what we were trying to do.
By using --prefix=${EPREFIX}/usr (the default) with --destdir ${T} and
--skip-subprojects glib, we were having to pray that running everything
with LD_LIBRARY_PATH & friends set would work out, rather than installing
it properly to ${T} and letting RPATH do its job. We now let Meson install
glib and gobject-introspection properly to ${T}/bootstrap-gi-prefix and
tell everything where to find it.
As for why it didn't show up earlier in glibc stage3s w/o glib already installed:
musl doesn't have libm.so, it does have a stub libm.a. glibc has a stub libm.so
nowadays as it merged everything in to libc.so.
I haven't cleaned up all the previous workarounds and hacks which may
no longer be needed in case we need to do more meddling here.
Thanks to Eli for both letting me rubberduck and also giving critical
suggestions that made the problem (and solution) obvious.
Closes: https://bugs.gentoo.org/945911
Thanks-to: Eli Schwartz <eschwartz@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>