search

sgerrand / alpine-pkg-glibc

A glibc compatibility layer package for Alpine Linux
2.04k stars 280 forks source link

2.35-r0 missing lib64 symlink #175

Open nvx opened 2 years ago

nvx commented 2 years ago

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 2 years ago

This is also the reason behind build failures involving glibc applications on alpine base images, e.g like in https://github.com/sgerrand/alpine-pkg-glibc/issues/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 2 years ago

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 2 years ago

btw this is the commit that changed the behavior https://github.com/sgerrand/alpine-pkg-glibc/commit/ddfe092f3d91c19f6cf8cb9f2938e088db4bfa8f. 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 1 year ago

The same as #176 and #181.

prantlf commented 1 year ago

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