libcrypt: arm64 / x86_64 different dependencies on EL9 #888
Milestone
Comments
output on arm64 with libxcrypt-compat installed
output on x86_64 without libxcrypt-compat installed
output on x86_64 with libxcrypt-compat installed
|
|
We had a similar experience with Amazon Linux 2023. But then, should tc-native go with |
|
hmm then the issue is that the x86_64 binary does not depend on libxcrypt-compat? |
|
Are you sure that legacy |
|
uh, how did you check? what packages are the legacy ones? in x64: $ rpm -qa | grep crypt
crypto-policies-20240202-1.git283706d.el9.noarch
libxcrypt-4.4.18-3.el9.x86_64
libgcrypt-1.10.0-10.el9_2.x86_64
cryptsetup-libs-2.6.0-3.el9.x86_64
crypto-policies-scripts-20240202-1.git283706d.el9.noarch
libxcrypt-devel-4.4.18-3.el9.x86_64
cryptsetup-2.6.0-3.el9.x86_64
$ cd /lib64
$ ls *crypt*
libcrypto.so libcrypto.so.3.0.7 libcryptsetup.so.12.9.0 libcrypt.so.2 libgcrypt.so.20 libk5crypto.so.3
libcrypto.so.3 libcryptsetup.so.12 libcrypt.so libcrypt.so.2.0.0 libgcrypt.so.20.4.0 libk5crypto.so.3.1
cryptsetup:
libcryptsetup-token-systemd-pkcs11.so libcryptsetup-token-systemd-tpm2.so
$ sudo dnf install libxcrypt-compat
...
$ ls *crypt*
libcrypto.so libcryptsetup.so.12 libcrypt.so.1 libcrypt.so.2.0.0 libk5crypto.so.3
libcrypto.so.3 libcryptsetup.so.12.9.0 libcrypt.so.1.1.0 libgcrypt.so.20 libk5crypto.so.3.1
libcrypto.so.3.0.7 libcrypt.so libcrypt.so.2 libgcrypt.so.20.4.0
cryptsetup:
libcryptsetup-token-systemd-pkcs11.so libcryptsetup-token-systemd-tpm2.so
$ ls -la libcrypt.so
lrwxrwxrwx. 1 root root 17 Feb 10 2022 libcrypt.so -> libcrypt.so.2.0.0
$ rpm -qf libcrypt.so.2
libxcrypt-4.4.18-3.el9.x86_64
$ rpm -qf libcrypt.so.1
libxcrypt-compat-4.4.18-3.el9.x86_64 |
|
I just returned from vacation but I think we should be able to not depend on libcrypt in general... need to look into it. |
flozano
changed the title
|
is this netty-tcnative or netty-tcnative-boringssl-static ? |
|
netty-tcnative-boringssl-static in my case. |
|
hmm netty-tcnative-boringssl-static should not depend on libcrypt @slandelle ... what version ? |
|
Yes, netty-tcnative-boringssl-static (2.0.66) in my case also. here I posted the list of netty JARs in the classpath when reproducing (aside from netty-common-999.2-SNAPSHOT.jar which is mine and has a really bad name as you can see) |
|
in x86_64 ldd does not show any dependency: $ unzip ../netty-tcnative-boringssl-static-2.0.66.Final-linux-x86_64.jar
Archive: ../netty-tcnative-boringssl-static-2.0.66.Final-linux-x86_64.jar
creating: META-INF/
inflating: META-INF/MANIFEST.MF
creating: META-INF/license/
creating: META-INF/maven/
creating: META-INF/maven/io.netty/
creating: META-INF/maven/io.netty/netty-tcnative-boringssl-static/
creating: META-INF/native/
creating: META-INF/versions/
creating: META-INF/versions/11/
inflating: META-INF/LICENSE.txt
inflating: META-INF/NOTICE.txt
inflating: META-INF/license/LICENSE.aix-netbsd.txt
inflating: META-INF/license/LICENSE.boringssl.txt
inflating: META-INF/license/LICENSE.mvn-wrapper.txt
inflating: META-INF/license/LICENSE.tomcat-native.txt
inflating: META-INF/maven/io.netty/netty-tcnative-boringssl-static/pom.properties
inflating: META-INF/maven/io.netty/netty-tcnative-boringssl-static/pom.xml
inflating: META-INF/native/libnetty_tcnative_linux_x86_64.so
inflating: META-INF/versions/11/module-info.class
inflating: META-INF/INDEX.LIST
$ ldd META-INF/native/libnetty_tcnative_linux_x86_64.so
ldd: warning: you do not have execution permission for `META-INF/native/libnetty_tcnative_linux_x86_64.so'
linux-vdso.so.1 => (0x00007ffcd072c000)
librt.so.1 => /lib64/librt.so.1 (0x00007fba0c640000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fba0c424000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fba0c220000)
libc.so.6 => /lib64/libc.so.6 (0x00007fba0be53000)
/lib64/ld-linux-x86-64.so.2 (0x00007fba0cc88000)but in aarch64 it does: $ unzip ../netty-tcnative-boringssl-static-2.0.66.Final-linux-aarch_64.jar
Archive: ../netty-tcnative-boringssl-static-2.0.66.Final-linux-aarch_64.jar
creating: META-INF/
inflating: META-INF/MANIFEST.MF
creating: META-INF/license/
creating: META-INF/maven/
creating: META-INF/maven/io.netty/
creating: META-INF/maven/io.netty/netty-tcnative-boringssl-static/
creating: META-INF/native/
creating: META-INF/versions/
creating: META-INF/versions/11/
inflating: META-INF/LICENSE.txt
inflating: META-INF/NOTICE.txt
inflating: META-INF/license/LICENSE.aix-netbsd.txt
inflating: META-INF/license/LICENSE.boringssl.txt
inflating: META-INF/license/LICENSE.mvn-wrapper.txt
inflating: META-INF/license/LICENSE.tomcat-native.txt
inflating: META-INF/maven/io.netty/netty-tcnative-boringssl-static/pom.properties
inflating: META-INF/maven/io.netty/netty-tcnative-boringssl-static/pom.xml
inflating: META-INF/native/libnetty_tcnative_linux_aarch_64.so
inflating: META-INF/versions/11/module-info.class
inflating: META-INF/INDEX.LIST
$ ldd META-INF/native/libnetty_tcnative_linux_aarch_64.so
ldd: warning: you do not have execution permission for `META-INF/native/libnetty_tcnative_linux_aarch_64.so'
linux-vdso.so.1 (0x0000ffffbe8bf000)
librt.so.1 => /lib64/librt.so.1 (0x0000ffffbe861000)
libcrypt.so.1 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x0000ffffbe840000)
libc.so.6 => /lib64/libc.so.6 (0x0000ffffbe442000)
/lib/ld-linux-aarch64.so.1 (0x0000ffffbe882000)
$ |
|
ah ok... so only on aarch64 it depends on libcrypt. This makes sense and I can fix that. |
|
Same thing here: 2.0.66. And indeed we only experience this issue on ARM. |
|
note also that x86_64 links to libpthread whereas aarch64 does not. |
normanmaurer
added a commit
that referenced
this issue
Oct 24, 2024
…bcrypt dependency. Motivation: We don't need to depend on libcrypt when cross-compiling. We already don't depend on it when we don't cross-compile Modifications: Patch APR as part of the docker image creation and so remove libcrypt dependency Result: Fixes #888
|
Fixed by #891 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
EDIT: Likely same as #722
When using tcnative with BoringSSL in arm64, when doing
OpenSsl.ensureAvailability()to verify everything works well, it fails unless the package libxcrypt-compat is installed. If installed it works well, if not:full error
in EL9/x86_64 however without libxcrypt-compat package being installed, the same code works well.
The text was updated successfully, but these errors were encountered: