Build does not produce statically linked binary anymore (on musl hosts)

[mgoltzsche]

Description

Calling make static is no longer producing a statically linked binary since release v1.1.8.
The produced binary is dynamically linked to musl libc.

Steps to reproduce the issue

Compile static runc v1.1.8 binary (on alpine:3.18 with Go 1.18):

1. Install packages:

apk add --update --no-cache gcc musl-dev libseccomp-dev libseccomp-static make git bash

2. Build runc:

git clone --branch v1.1.9 https://github.com/opencontainers/runc runc
cd runc
make static 'BUILDTAGS=seccomp selinux ambient'

3. Inspect the produced binary:

$ ldd runc
/lib/ld-musl-x86_64.so.1 (0x7feebc024000)

With runc v1.1.7 this was producing a statically linked binary but stopped doing so with the v1.1.8 release.

Describe the results you received and expected

ldd runc should fail with /lib/ld-musl-x86_64.so.1: /usr/local/bin/runc: Not a valid dynamic program as it did with runc v1.1.7.

What version of runc are you using?

v1.1.8

Host OS information

$ cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.17.4
PRETTY_NAME="Alpine Linux v3.17"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"

Host kernel information

$ uname -a
Linux 8860fbc8c11f 5.19.0-50-generic #50-Ubuntu SMP PREEMPT_DYNAMIC Mon Jul 10 18:24:29 UTC 2023 x86_64 Linux

[thaJeztah]

Looking at the diff:

v1.1.7...v1.1.8

My initial suspect would be this PR;

• Backport riscv64 support into 1.1.x #3905

There's not too many commits between v1.1.7 and v1.1.8, so perhaps a git-bisect would work?

[cyphar]

The binaries built for the release are all static AFAICS, so this isn't a problem with our regular builds:

% file release/1.1.8/* | grep ELF
release/1.1.8/runc.amd64:                  ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, BuildID[sha1]=bd103582c4e720790d7be29e5f939124cb3bd46d, for GNU/Linux 3.2.0, stripped
release/1.1.8/runc.arm64:                  ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), static-pie linked, BuildID[sha1]=27dfd50de28a6eb89af56873996636cee242c854, for GNU/Linux 3.7.0, stripped
release/1.1.8/runc.armel:                  ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=feff5f892e34b3849d272f10d3bcefba347db4c5, for GNU/Linux 3.2.0, stripped
release/1.1.8/runc.armhf:                  ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=de305e182e9d5708b12d848a20456b90ab83c3f9, for GNU/Linux 3.2.0, stripped
release/1.1.8/runc.ppc64le:                ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, OpenPOWER ELF V2 ABI, version 1 (SYSV), statically linked, BuildID[sha1]=52b713468c60e8bb0ac738ab16c0bb4c11c4460f, for GNU/Linux 3.10.0, stripped
release/1.1.8/runc.riscv64:                ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), statically linked, BuildID[sha1]=10dc1b79c0d513f3f828b33afaacbaa8e3545b15, for GNU/Linux 4.15.0, stripped
release/1.1.8/runc.s390x:                  ELF 64-bit MSB executable, IBM S/390, version 1 (SYSV), statically linked, BuildID[sha1]=0e8e57f7cda35380b4a5eb51e3af87b65f23fabf, for GNU/Linux 3.2.0, stripped

I suspect the issue is that the riscv patchset switched to using --static-pie on platforms where it is supported on glibc -- and it seems that musl doesn't support that? To quote the comment:

# Enable static PIE executables on supported platforms.
# This (among the other things) requires libc support (rcrt1.o), which seems
# to be available only for arm64 and amd64 (Debian Bullseye).

I'm not sure if there's a nice way to detect whether the libc we're using supports --static-pie other than doing the build (which would be quite ugly to do in make). I'm surprised the build doesn't error out when passing -extldflags --static-pie... @kolyshkin?

[Zheaoli]

Looking at the diff:

v1.1.7...v1.1.8

My initial suspect would be this PR;

• Backport riscv64 support into 1.1.x #3905

There's not too many commits between v1.1.7 and v1.1.8, so perhaps a git-bisect would work?

No, I think the root cause be here 923ae4d

[Zheaoli]

I'm not sure if there's a nice way to detect whether the libc we're using supports --static-pie other than doing the build (which would be quite ugly to do in make). I'm surprised the build doesn't error out when passing -extldflags --static-pie... @kolyshkin?

Yep, the musl in alpine is not support the static pie, there are multiple report in the community like

rust-lang/cargo#5266
coreos/butane#87

I think maybe we can limit the static pie compile for Debian/Ubuntu & GNU libc platform?