Building with musl target fails locally

[fabriziosestito]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

Building with musl target fails locally. Both the Dockerfile and cargo build --release --target=x86_64-unknown-linux-musl fail with the same error:

  = note: /sbin/ld: /usr/lib/libm-2.40.a(s_truncf.o): warning: relocation against `_dl_x86_cpu_features' in read-only section `.text'
          /sbin/ld: /usr/lib/libm-2.40.a(w_exp.o): in function `__exp':
          (.text+0x62): undefined reference to `errno'
          /sbin/ld: /usr/lib/libm-2.40.a(w_log.o): in function `__log':
          (.text+0x1f): undefined reference to `errno'
          /sbin/ld: /usr/lib/libm-2.40.a(w_pow.o): in function `__pow':
          (.text+0x7a): undefined reference to `errno'
          /sbin/ld: (.text+0xb8): undefined reference to `errno'
          /sbin/ld: /usr/lib/libm-2.40.a(e_exp.o): in function `__ieee754_exp_ifunc':
          (.text+0x236): undefined reference to `_dl_x86_cpu_features'
          /sbin/ld: (.text+0x241): undefined reference to `_dl_x86_cpu_features'
          /sbin/ld: (.text+0x24a): undefined reference to `_dl_x86_cpu_features'
          /sbin/ld: /usr/lib/libm-2.40.a(e_log.o): in function `__ieee754_log_ifunc':
          (.text+0x2c6): undefined reference to `_dl_x86_cpu_features'
          /sbin/ld: (.text+0x2d1): undefined reference to `_dl_x86_cpu_features'
          /sbin/ld: /usr/lib/libm-2.40.a(e_log.o):(.text+0x2da): more undefined references to `_dl_x86_cpu_features' follow
          /sbin/ld: /usr/lib/libm-2.40.a(math_err.o): in function `with_errno':
          (.text+0x3): undefined reference to `errno'
          /sbin/ld: read-only segment has dynamic relocations
          collect2: error: ld returned 1 exit status

However, the CI build job is working fine.

This seems to be related to: https://github.com/bytecodealliance/wasmtime/issues/8898 Buidling with the suggested CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=musl-gcc results in a binary that terminates with fish: Job 1, './target/x86_64-unknown-linux-m…' terminated by signal SIGSEGV (Address boundary error).

Expected Behavior

No response

Steps To Reproduce

No response

Environment

Arch Linux  6.9.9-arch1-1 x86/64

pacman -Qi /sbin/musl-gcc 

Name            : musl
Version         : 1.2.5-2
Description     : Lightweight implementation of C standard library
Architecture    : x86_64
URL             : https://www.musl-libc.org/
Licenses        : MIT
Groups          : None
Provides        : None
Depends On      : None
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 3.68 MiB
Packager        : Sergej Pupykin <spupykin@archlinux.org>
Build Date      : Mon 15 Jul 2024 03:00:15 AM CEST
Install Date    : Thu 25 Jul 2024 07:15:41 AM CEST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

### Anything else?

_No response_

[viccuad]

I can confirm the same. Debian Stable with musl-gcc from musl 1.2.3-1.

Click here

``` $ dpkg --search /usr/bin/musl-gcc musl-tools: /usr/bin/musl-gcc $ dpkg --status musl-tools Package: musl-tools Status: install ok installed Priority: optional Section: devel Installed-Size: 61 Maintainer: Reiner Herrmann Architecture: amd64 Source: musl Version: 1.2.3-1 Replaces: musl (<< 1.1.15-1) Depends: musl-dev (= 1.2.3-1) Breaks: musl (<< 1.1.15-1) Description: standard C library tools musl is lightweight, fast, simple, free and strives to be correct in the sense of standards-conformance and safety. . This package contains the musl-gcc wrapper script for the native architecture, to make easy-to-deploy static and minimal dynamically linked programs. Homepage: https://musl.libc.org/ $ musl-gcc --version x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ```

[flavio]

However, the CI build job is working fine.

You mean the CI job that builds the container image?

[jvanz]

You mean the CI job that builds the container image?

Exactly. We cannot build locally using the Dockerfile in the repository. But the CI is working fine. This is an issue found during the v1.15 while we would like to build the container image for testing.

[flavio]

This is going to be solved by https://github.com/kubewarden/policy-server/pull/874

[flavio]

Building outside of docker, using musl-gcc is still failing. Should we leave this issue open or just close it?

I would close it, since this is a scenario we don't care about. Building locally, for quick testing with something like postman, can be done using a non-statically linked binary

[viccuad]

fair enough, closing then since it's not particularly actionable on our side.