sgerrand/alpine-pkg-glibc

2.35-r0 missing lib64 symlink

nvx opened this issue · 6 comments

nvx commented

2.34-r0 release:

# apk info -L glibc | grep lib64
lib64/ld-linux-x86-64.so.2
usr/glibc-compat/lib64/ld-linux-x86-64.so.2

Meanwhile the 2.35-r0 release:

# apk info -L glibc | grep lib64
usr/glibc-compat/lib64/ld-linux-x86-64.so.2

This causes some applications to fail as they're linked against /lib64 according to ldd.

As an aside I also noticed libSegFault.so is missing in the new version, but I'm not sure if that's a problem or not.

snw35 commented

This is also the reason behind build failures involving glibc applications on alpine base images, e.g like in #176

Working and broken container examples below:


# Broken
podman run -it --rm snw35/awscli:2.5.2 sh

/opt # aws --version
Error relocating /usr/local/bin/aws: __strcat_chk: symbol not found
Error relocating /usr/local/bin/aws: __snprintf_chk: symbol not found
Error relocating /usr/local/bin/aws: __vfprintf_chk: symbol not found
Error relocating /usr/local/bin/aws: __realpath_chk: symbol not found
Error relocating /usr/local/bin/aws: __memcpy_chk: symbol not found
Error relocating /usr/local/bin/aws: __vsnprintf_chk: symbol not found
Error relocating /usr/local/bin/aws: __strcpy_chk: symbol not found
Error relocating /usr/local/bin/aws: __fprintf_chk: symbol not found

/opt # ls -lah /lib64/
total 8K     
drwxr-xr-x    2 root     root        4.0K Apr  3 12:15 .
dr-xr-xr-x   20 root     root        4.0K Apr  4 23:38 ..
lrwxrwxrwx    1 root     root          26 Apr  3 12:15 ld-linux-x86-64.so.2 -> /lib/libc.musl-x86_64.so.1


# Working
podman run -it --rm snw35/awscli:2.4.25 sh

/opt # aws --version
aws-cli/2.4.25 Python/3.8.8 Linux/5.16.18-200.fc35.x86_64 exe/x86_64.alpine.3 prompt/off

/opt # ls -alh /lib64/
total 8K     
drwxr-xr-x    2 root     root        4.0K Mar 13 12:13 .
dr-xr-xr-x   20 root     root        4.0K Apr  4 23:42 ..
lrwxrwxrwx    1 root     root          42 Mar 13 12:13 ld-linux-x86-64.so.2 -> /usr/glibc-compat/lib/ld-linux-x86-64.so.2
python-and-fiction commented

sure,after installed 2.35-r0,something doesn't work ,programs based on glibc won't work.
it's become correct when i add symlink /lib64 -> /lib

pablosole commented

btw this is the commit that changed the behavior ddfe092. it looks like the apk packager complained about it so it was removed.

Funnily enough, the code in apkbuild understood exactly what this package is doing but considers it an error anyway (https://github.com/alpinelinux/abuild/blob/master/abuild.in#L766):

	# Alpine Linux as a musl libc distro does not use /lib64 or /usr/lib64 under
	# any circumstance, packages installing to it are 100% sure a packaging error
	# except when we are doing GNU Libc compatibility which should be rare enough
	# to warrant a lib64 check
prantlf commented

The same as #176 and #181.

prantlf commented

My crude workaround to do in a Dockerfile after installing glibc-2.35-r0.apk:

mkdir -p /lib64
ln -sf /usr/glibc-compat/lib/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2
  • 👍9
mattbucci commented

ln -sf /usr/glibc-compat/lib/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2

This works on x86 but for some reason on aarch64 the equivalent doesn't seem to work

ln -sf /usr/glibc-compat/lib/ld-linux-aarch64.so.1 /lib64/ld-linux-aarch64.so.1

it has to be

ln -sf /usr/glibc-compat/lib/ld-linux-aarch64.so.1 /lib/ld-linux-aarch64.so.1

I'm not sure why it shouldn't be the 64bit lib folder. You can check this using

/ # patchelf --print-interpreter /root/miniforge3/_conda
/lib/ld-linux-aarch64.so.1