Puppy Linux Discussion Forum

Am I missing something here? I can't find it in the repos ..

What program are you attempting to run?
In Ubuntu 20.04, libcrypt.so.1 is provided by libxcrypt in the libcrypt1 package.

Search for libxcrypt in the PPM and install it

rockedge wrote: Wed Jun 09, 2021 12:21 pm

What program are you attempting to run?
In Ubuntu 20.04, libcrypt.so.1 is provided by libxcrypt in the libcrypt1 package.

I've already tried searching for 'libcrypt1' in the Easy repos. No joy.

Isn't libcrypt.so.1 one of those libs that is supposed to be in every linux? A part of glibc?

I guess it doesn't matter since any apps written that need some variant of libcrypt are going to fail, which in turn will require the user to find a solution on their own.

@Jafadmin can you search for and find libxcrypt? I am wondering if installing this will solve the dependency

rockedge wrote: Wed Jun 09, 2021 12:44 pm

@Jafadmin can you search for and find libxcrypt? I am wondering if installing this will solve the dependency

That's already installed by default. The dep still fails.

Ok, I figured it out. The needed libs are in '/usr/lib' as 'libcrypto.so.1.1' or 'libcrypt.so.2.0.0'

So it becomes necessary to put a 'libcrypt.so.1' link in '/lib' that points to either of those files.

Take note that the spelling of 'libcrypto.so.1.1' isn't the standard spelling. It has one too many 'o's in it.

So from the sakura terminal:

# ln -s /usr/lib/libcrypt.so.2.0.0  /usr/lib/libcrypt.so.1

[Edit] That symlink should stay in '/usr/lib', I think, instead of in '/lib'.

So now how do we make this "Easy" for the newby end user?

Just my 0.02$: It might be a good idea to have symlinks for 'libcrypt.so.1' and 'libcrypt.so.2' in '/lib' that both point to '/usr/lib/libcrypt.so.2.0.0' since it is supposed to be, and is expected to be, part of the Linux Standard Base specification.

'libcrypt.so.2' appears to be backwardly compatible according to documentation, and according to my tests ..

I first was going to write "symlinks needed" ! I run into variants of this problem with some of the experiments I conduct and fixed many a problem with symlinking

rockedge wrote: Wed Jun 09, 2021 1:40 pm

I first was going to write "symlinks needed" ! I run into variants of this problem with some of the experiments I conduct and fixed many a problem with symlinking

The reason I tagged this as a workaround is that it works, but shouldn't be needed. The whole idea behind "Easy" is that the user shouldn't have to chase around after standard libs in order to install and run software they choose to install.

I'm certain this is a mere oversight. A couple symlinks in the next roll should suffice.

@Jafadmin
What application has required this libcrypt.so.1?

EasyOS has libcrypt.so.2

All packages installable from the package manager should work. If there is one that wants libcrypt.so.1, please tell me.

If you you are trying to run a PET from elsewhere, then no guarantees it will work, it may have library incompatibilities, such as wanting an older libcrypt version.

@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.

Jafadmin wrote: Thu Jun 10, 2021 5:52 pm

@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.

BarryK wrote: Fri Jun 11, 2021 11:13 am

Jafadmin wrote: Thu Jun 10, 2021 5:52 pm

@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.

Jafadmin wrote: Fri Jun 11, 2021 3:06 pm

BarryK wrote: Fri Jun 11, 2021 11:13 am

Jafadmin wrote: Thu Jun 10, 2021 5:52 pm

@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.

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.

BarryK wrote: Sat Jun 12, 2021 9:32 am

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.

Jafadmin wrote: Sat Jun 12, 2021 10:02 am

BarryK wrote: Sat Jun 12, 2021 9:32 am

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.