While debugging https://bugs.gentoo.org/929227 in a musl-gcc chroot I came across an unrelated follow-up problem where the build would fail with a linker error due to missing libanl, an empty stub library for async dns resolution. The musl stage3 tarballs already contain a related empty stub for librt: $cat musl-gcc/lib/librt.a !<arch> A simple cp -a /lib/librt.a /lib/libanl.a creates the missing stub and lets the build succeed. IMHO shipping an additional empty stub is much easier and more consistent than patching ebuilds.
afaik musl does not implement functions from libanl, e.g. musl lacks getaddrinfo_a(). Stub only makes sense if the main libc actually has the functions. The library existing could in fact mislead some build systems and lead to new failures. If a build succeed thanks to a stub on musl may just be that the package did not need libanl in the first place (perhaps used a different code path but still attempted to link with it or so). Also it's generally better to avoid inventing downstream workarounds like that, if musl upstream wanted to supply extra stubs then I wouldn't say.
(In reply to Ionen Wolkens from comment #1) > If a build succeed thanks to a stub on musl may just be that the package did > not need libanl in the first place (perhaps used a different code path but > still attempted to link with it or so). Grepping the falcosecurity-libs, I see it use normal getaddrinfo() but no _a anywhere. Attempting to link with libanl seems just like a build system problem. Also funny enough the anl bit is behind: option(MUSL_OPTIMIZED_BUILD "Enable if you want a musl optimized build" OFF) if(NOT MUSL_OPTIMIZED_BUILD) list(APPEND SINSP_LIBRARIES rt anl) endif() So setting MUSL_OPTIMIZED_BUILD if use elibc_musl would probably solve this.
That's what THEY want you to believe! Unfortunately setting MUSL_OPTIMIZED_BUILD will result in an attempt to all-static linking further down the road, which then fails in other ways. This has all been removed upstream since they couldn't build their own stuff any more either. I fully understand that adding the stub lib is questionable, but then so is adding stub librt. :( I'll give removing the libanl link step a try.
(In reply to Holger Hoffstätte from comment #3) > That's what THEY want you to believe! Unfortunately setting > MUSL_OPTIMIZED_BUILD will result in an attempt to all-static linking further > down the road, which then fails in other ways. This has all been removed > upstream since they couldn't build their own stuff any more either. I see, too bad. > I fully understand that adding the stub lib is questionable, but then so is > adding stub librt. :( That's not the same situation for two reasons: 1. musl *does* implement librt's functions, unlike libanl 2. musl upstream is the one providing this (we're not adding it), so all normal musl systems will have it (./configure && make install creates a librt.a even without the ebuild)
I've managed to conditionally remove the libanl reference and verified that this has no negative effect on glibc (csysdig runs fine), so this can be closed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=844fbd1e96beda0fb94ea06aba8f2618bfdad1f7 commit 844fbd1e96beda0fb94ea06aba8f2618bfdad1f7 Author: Holger Hoffstätte <holger@applied-asynchrony.com> AuthorDate: 2024-04-13 13:58:37 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-05-20 15:52:38 +0000 dev-debug/sysdig: don't try to link against libanl on musl libanl is an empty stub library since glibc-2.34 and does not exist on musl. Since sysdig uses c-ares and therefore does not even need glibc's async name lookups, we can safely remove it when building on musl. Bug: https://bugs.gentoo.org/929227 Bug: https://bugs.gentoo.org/929907 Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com> Closes: https://github.com/gentoo/gentoo/pull/36237 Signed-off-by: Mike Gilbert <floppym@gentoo.org> dev-debug/sysdig/files/0.29.3-libs-no-libanl.patch | 16 ++++++++++++++++ dev-debug/sysdig/sysdig-0.29.3-r2.ebuild | 12 +++++++++--- 2 files changed, 25 insertions(+), 3 deletions(-)