Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.35-r0 missing lib64 symlink #175

Open
nvx opened this issue Mar 16, 2022 · 5 comments
Open

2.35-r0 missing lib64 symlink #175

nvx opened this issue Mar 16, 2022 · 5 comments

Comments

@nvx
Copy link

nvx commented Mar 16, 2022

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
Copy link

snw35 commented Apr 4, 2022

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
Copy link

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
Copy link

pablosole commented Jun 2, 2022

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
Copy link

prantlf commented Oct 23, 2022

The same as #176 and #181.

@prantlf
Copy link

prantlf commented Nov 21, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants