Bug 929907 – musl stage3 tarballs should contain empty libanl stub library for compatibiity

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Holger Hoffstätte 2024-04-13 12:53:25 UTC]

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.

[Comment 1 Ionen Wolkens 2024-04-13 13:20:21 UTC]

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.

[Comment 2 Ionen Wolkens 2024-04-13 13:26:55 UTC]

(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.

[Comment 3 Holger Hoffstätte 2024-04-13 13:35:49 UTC]

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.

[Comment 4 Ionen Wolkens 2024-04-13 13:48:09 UTC]

(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)

[Comment 5 Holger Hoffstätte 2024-04-13 14:19:30 UTC]

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.

[Comment 6 Larry the Git Cow 2024-05-20 15:53:18 UTC]

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 <[e-mail]>
AuthorDate: 2024-04-13 13:58:37 +0000
Commit:     Mike Gilbert <[e-mail]>
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 <[e-mail]>
    Closes: https://github.com/gentoo/gentoo/pull/36237
    Signed-off-by: Mike Gilbert <[e-mail]>

 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(-)