age: aarch64-musl package contains glibc-linked binaries

[vs-123]

Is this a new report?

Yes

System Info

Void 6.12.67_1 aarch64-musl Unknown uptodate r

Package(s) Affected

age-1.3.1_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No response

Expected behaviour

Most binaries in age package (version 1.3.1_1) in the aarch64-musl repository seem to be linked against glibc instead of musl.

Actual behaviour

Attempting to run age-keygen, age-inspect or age-plugin-batchpass, gives no such file or directory in shell because they are dynamically linked against /lib/ld-linux-aarch64.so.1 (glibc) instead of /lib/ld-musl-aarch64.so.1.

% file $(which age-inspect)
/usr/bin/age-inspect: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=cc4caed281633f51cf8e2f7dd1878717d383ca41, stripped

% file $(which age-plugin-batchpass)
/usr/bin/age-plugin-batchpass: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=2a32da9daf1b0f18ba93aebf44dceddfbf82303f, stripped

% file $(which age-keygen)
/usr/bin/age-keygen: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=f8a7ffab717b032227ec84c90e687022040faf8d, stripped

Steps to reproduce

1. Install age package on an AArch64 Void Linux musl system --> xbps-install -S age
2. Try to run any of --> age-keygen, age-inspect, age-plugin-batchpass
3. You get zsh: command not found or no such file or directory or the equivalent in your shell.
4. Try checking what they're linked against using ldd, you'd get something like:

% ldd /usr/bin/age-keygen
	/lib/ld-linux-aarch64.so.1 (0xffffba3d0000)

% ldd /usr/bin/age-inspect
	/lib/ld-linux-aarch64.so.1 (0xffff8a520000)

% ldd /usr/bin/age-plugin-batchpass 
	/lib/ld-linux-aarch64.so.1 (0xffffa4c40000)

[dkwo]

Does it link correctly if you rebuild it natively?
I am afraid I introduced this when building it with pie.

[dkwo]

btw, have you seen golang/go#45034 ?

[dkwo]

I guess the fix to that issue salewski/go@9f2a71b may not work for cross (i.e. cross + pie)?

[Duncaen]

Removing -buildmode=pie fixes it, looks like the age binary requires cgo and the other binaries that get the wrong dynamic linker don't require cgo and are in this case build statically if pie is not used.

[vs-123]

Confirmed. I rebuilt age using xbps-src with -buildmode=pie removed and the binaries now link correctly and execute on aarch64-musl.

[vs-123]

I've submitted a PR to fix this --> #58791

[dkwo]

This is strange: if you look at how age is built at https://github.com/FiloSottile/age/blob/10561a774f9f6de47c8d23ddc58537b6a18b083d/.github/workflows/build.yml#L60 , they set cgo=0.
@vs-123 Could you try rebuild locally but with pie enabled?

[classabbyamp]

cgo is enabled by default:

void-packages/common/environment/build-style/go.sh

Line 41 in 075aa49

export CGO_ENABLED="${CGO_ENABLED:-1}"

export CGO_ENABLED=0 in the template might fix it

[Duncaen]

I think its the opposite, it works when linked with CGO because that invokes the external linker by default, but doesn't when its using go's own linker. I quickly looked at the source but couldn't find anything obvious to why it would use that dynamic loader since it should actually stat and fall back to musl.

[Duncaen]

Yea setting CGO_ENABLED=0 makes the binary that does work also use the wrong dynamic linker.

masterdir-x86_64-musl/builddir/age-1.3.1/_build-age-xbps/bin/linux_arm64/age:                  ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=55ab66b543959d1ef7943675f885eb9d8e1515ef, with debug_info, not stripped
masterdir-x86_64-musl/builddir/age-1.3.1/_build-age-xbps/bin/linux_arm64/age-inspect:          ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=c01792834b817145be995122916aea96ec867f2b, with debug_info, not stripped
masterdir-x86_64-musl/builddir/age-1.3.1/_build-age-xbps/bin/linux_arm64/age-keygen:           ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=f70bd02611840d093403b5eb8db844fbbb77f507, with debug_info, not stripped
masterdir-x86_64-musl/builddir/age-1.3.1/_build-age-xbps/bin/linux_arm64/age-plugin-batchpass: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=7dbd7d6d993893d2852611d3f52f78610c36887b, with debug_info, not stripped

[vs-123]

@dkwo I just did a side-by-side comparison of the binaries with and without PIE enabled.

It seems that enabling PIE makes Go use dynamic linking which then defaults to the glibc interpreter path /lib/ld-linux-aarch64.so.1. Without PIE Go makes a purely static ELF i.e. the desired behaviour for this package.

Without -buildmode=pie:

% file $(which age-keygen)
/usr/bin/age-keygen: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=d561d42e28ee19b6fafc356ef85ecf1200316a32, stripped

% file $(which age-inspect)
/usr/bin/age-inspect: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=466c0cd177c49321a214ce41f374c15b084133f4, stripped

% file $(which age-plugin-batchpass)
/usr/bin/age-plugin-batchpass: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=1bebd5e1d9b845b688859eedb42b636a6c0e725a, stripped

With -buildmode=pie:

% file $(which age-keygen)
/usr/bin/age-keygen: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=f8a7ffab717b032227ec84c90e687022040faf8d, stripped

% file $(which age-inspect)
/usr/bin/age-inspect: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=cc4caed281633f51cf8e2f7dd1878717d383ca41, stripped

% file $(which age-plugin-batchpass)
/usr/bin/age-plugin-batchpass: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=2a32da9daf1b0f18ba93aebf44dceddfbf82303f, stripped

[dkwo]

I think this is an issue with go, e.g. Alpine patches it like so https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/go/0001-cmd-link-prefer-musl-s-over-glibc-s-ld.so-during-dyn.patch (see also golang/go#62053 )

@vs-123 if you pass the linker explicitly, like -ldflags=-I/path/to/ld.so does it work?