Solution to missing 'libcrypt.so.1'? [Fixed]

[Jafadmin]

@BarryK

'libcrypt.so.2.0.0' does indeed exist, as does the symlink to it; 'libcrypt.so.2'

No libs need be added. All that is needed is a symlink to 'libcrypt.so.2.0.0' named 'libcrypt.so.1' in /usr/lib

'libcrypt.so.2' is backwardly compatable to 'libcrypt.so.1' so this works out fine. No additional binaries needed.

I realize that 'libcrypt.so.1' is deprecated and 'libcrypt.so.2' is the update to it. However, all the software that links to the older lib name fail without the symlink to the new lib.

This occurs because I'm writing compiled/linked code on a dev box, then running the binary on Easy. Easy is the first "puppy" I've tested on that doesn't have a 'libcrypt.so.1' symlink. Even the latest Ubuntu/Mint versions have the '.1' link.

[BarryK]

@BarryK

'libcrypt.so.2.0.0' does indeed exist, as does the symlink to it; 'libcrypt.so.2'

No libs need be added. All that is needed is a symlink to 'libcrypt.so.2.0.0' named 'libcrypt.so.1' in /usr/lib

'libcrypt.so.2' is backwardly compatable to 'libcrypt.so.1' so this works out fine. No additional binaries needed.

I realize that 'libcrypt.so.1' is deprecated and 'libcrypt.so.2' is the update to it. However, all the software that links to the older lib name fail without the symlink to the new lib.

This occurs because I'm writing compiled/linked code on a dev box, then running the binary on Easy. Easy is the first "puppy" I've tested on that doesn't have a 'libcrypt.so.1' symlink. Even the latest Ubuntu/Mint versions have the '.1' link.

OK.
It is sometimes not appropriate to symlink to a later library version, as it may be incompatible. But some library developers try to keep backwards compatibility.

[Jafadmin]

@BarryK

'libcrypt.so.2.0.0' does indeed exist, as does the symlink to it; 'libcrypt.so.2'

No libs need be added. All that is needed is a symlink to 'libcrypt.so.2.0.0' named 'libcrypt.so.1' in /usr/lib

'libcrypt.so.2' is backwardly compatable to 'libcrypt.so.1' so this works out fine. No additional binaries needed.

I realize that 'libcrypt.so.1' is deprecated and 'libcrypt.so.2' is the update to it. However, all the software that links to the older lib name fail without the symlink to the new lib.

This occurs because I'm writing compiled/linked code on a dev box, then running the binary on Easy. Easy is the first "puppy" I've tested on that doesn't have a 'libcrypt.so.1' symlink. Even the latest Ubuntu/Mint versions have the '.1' link.

OK.
It is sometimes not appropriate to symlink to a later library version, as it may be incompatible. But some library developers try to keep backwards compatibility.

It is SOP in this case. This is how Debian solves it.

[BarryK]

@BarryK

'libcrypt.so.2.0.0' does indeed exist, as does the symlink to it; 'libcrypt.so.2'

No libs need be added. All that is needed is a symlink to 'libcrypt.so.2.0.0' named 'libcrypt.so.1' in /usr/lib

'libcrypt.so.2' is backwardly compatable to 'libcrypt.so.1' so this works out fine. No additional binaries needed.

I realize that 'libcrypt.so.1' is deprecated and 'libcrypt.so.2' is the update to it. However, all the software that links to the older lib name fail without the symlink to the new lib.

This occurs because I'm writing compiled/linked code on a dev box, then running the binary on Easy. Easy is the first "puppy" I've tested on that doesn't have a 'libcrypt.so.1' symlink. Even the latest Ubuntu/Mint versions have the '.1' link.

OK.
It is sometimes not appropriate to symlink to a later library version, as it may be incompatible. But some library developers try to keep backwards compatibility.

It is SOP in this case. This is how Debian solves it.

OK, woofQ will now create this symlink.

libcrypt.so.2 is in the 'libxcrypt' package. I think that it used to be in glibc, older versions of glibc.
In woofQ, packages-templates/libxcrypt, script FIXUPHACK will create the symlink.

[BarryK]

Just looked at Debian packages, they have libcrypt1, so libcrypt.so.1 is NOT a symlink to libcrypt.so.2:

https://packages.debian.org/experimental/libcrypt1

However, as you report the symlink works, I will leave it in.

[Jafadmin]

Just looked at Debian packages, they have libcrypt1, so libcrypt.so.1 is NOT a symlink to libcrypt.so.2:

https://packages.debian.org/experimental/libcrypt1

However, as you report the symlink works, I will leave it in.

That's interesting. I'm looking at a "clean install" VM of Debian Buster right now that has it linked to libcrypt-2.28.so
I think we have the right fix.

libcrypt-link.png (58.36 KiB) Viewed 2431 times

[BarryK]

Just looked at Debian packages, they have libcrypt1, so libcrypt.so.1 is NOT a symlink to libcrypt.so.2:

https://packages.debian.org/experimental/libcrypt1

However, as you report the symlink works, I will leave it in.

That's interesting. I'm looking at a "clean install" VM of Debian Buster right now that has it linked to libcrypt-2.28.so
I think we have the right fix.
libcrypt-link.png

Ah, yes, I think that glibc 2.28 (in buster I presume) has that library in it. glibc 2.30+ has removed it, and it is a separate package, libxcrypt. I was looking at the unstable debian.