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

Wrong SONAME for alpha #96

Open
rfc1036 opened this issue Dec 28, 2019 · 5 comments
Open

Wrong SONAME for alpha #96

rfc1036 opened this issue Dec 28, 2019 · 5 comments
Labels
bug Confirmed to be a bug in libxcrypt. help wanted The libxcrypt core developers do not plan to work on this themselves but would review a PR. os-linux Issues specific to Linux.

Comments

@rfc1036
Copy link

rfc1036 commented Dec 28, 2019

A Debian porter noticed that alpha and ia64 use libcrypt.so.1.1 instead of libcrypt.so.1.
I am not even sure that it is possible for libcrypt to use a SONAME like this, so for the time being I am patching libtool in the build directory:

perl -i -pe '/^(library_names_spec|soname_spec)=/ and s/major/major.1/'

@zackw
Copy link
Collaborator

zackw commented Dec 29, 2019

Good catch, thanks. Unfortunately I don't think libtool supports sonames like this at all. I've got an experimental branch in which we build with meson instead, and I'll see if that can do it. (However, is it a potential problem for porters and/or new architectures if we use meson instead of autotools? You'd know better than me/)

@rfc1036
Copy link
Author

rfc1036 commented Dec 29, 2019

I have no experience at all with Meson, but since it is written in pure Python I suppose that it works on all Debian architectures.

@besser82
Copy link
Owner

besser82 commented Jan 3, 2020

From the perspective of bootstrapping new architectures from scratch there shouldn't be any problems as they need to be cross-compiled, which is perfectly supported by meson, on some existing system with a working Python3 to get a basic stage-1 image/tarball anyways.

@rfc1036
Copy link
Author

rfc1036 commented Jul 9, 2020

Actually the soname is wrong only on alpha, ia64 is "standard".

@rfc1036 rfc1036 changed the title Wrong SONAME for alpha and ia64 Wrong SONAME for alpha Oct 11, 2020
@mattst88
Copy link

I can confirm that glibc installs libcrypt.so.1.1 on alpha (and libc.so.6.1, presumably due to the same SONAME bump long ago):

$ qlist glibc | grep libcrypt.so.1
/lib/libcrypt.so.1.1
/usr/lib/libcrypt.so

while libxcrypt installs libcrypt.so.1:

$ qlist libxcrypt | grep libcrypt.so.1
/lib/libcrypt.so.1.1.0
/lib/libcrypt.so.1

On Gentoo, we rebuilt reverse dependencies of libcrypt when doing this transition, so it was not a problem for us. I believe this would have been a problem for a binary distribution that would necessitate a rebuild, since the SONAME in binaries is indeed libcrypt.so.1.1:

$ readelf -a /usr/sbin/sshd  |& grep libcrypt.so
 0x0000000000000001 (NEEDED)             Shared library: [libcrypt.so.1.1]
  000000: Version: 1  File: libcrypt.so.1.1  Cnt: 1

On ia64, glibc installs libcrypt.so.1 and libxcrypt does the same:

$ qlist glibc | grep libcrypt.so.1
/lib/libcrypt.so.1
$ qlist libxcrypt | grep libcrypt.so.1
/lib/libcrypt.so.1.1.0
/lib/libcrypt.so.1

@zackw zackw added bug Confirmed to be a bug in libxcrypt. help wanted The libxcrypt core developers do not plan to work on this themselves but would review a PR. os-linux Issues specific to Linux. labels Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed to be a bug in libxcrypt. help wanted The libxcrypt core developers do not plan to work on this themselves but would review a PR. os-linux Issues specific to Linux.
Projects
None yet
Development

No branches or pull requests

4 participants