Andreas,
Yes, esql uses the -lcrypt linker option with gcc, which instructs the gcc compiler / ld linker to find the libcrypt.so.? shared lib the be referenced.
I suggest that you read about gcc, ld, and .so versioning on Linux
From my understanding:
You can can multiple versions of a shared lib on a production system (libcrypt.so.1 and libcrypt.so.2). These files usually are symbolic links to the "real" lib, with additional (minor) version numbers, that can change when updating the packages. For ex, on our RHE 9.2, we have in /usr/lib64: libcrypt.so.1 -> libcrypt.so.1.1.0 and libcrypt.so.2 -> libcrypt.so.2.0.0
The first number in .so.1 or .so.2 is a major version identifying ABI compatibility (any binary linked with libcrypt.so.1 can work with any libcrypt.so.1.*)
On your SLES 12.3 system it's confusing to me, because libcrypt.so.1 -> libcrypt-2.22.so (note that "-2" (minus 2) is part of the filename!) - you better make sure it's done intentionally by SUSE.
On Linux, you typically have 2 kind of packages: The runtime package, installing shared libs with version numbers; and the development package, installing also .h header files and a generic filename without version numbers that points to the latest shared lib.
On our RHE 9.2: libcrypt.so -> libcrypt.so.2.0.0
[comp@eiffel ~]$ rpm -qf /usr/lib64/libcrypt.so
libxcrypt-devel-4.4.18-3.el9.aarch64
[comp@eiffel ~]$ rpm -qf /usr/lib64/libcrypt.so.1
libxcrypt-compat-4.4.18-3.el9.aarch64
[comp@eiffel ~]$ rpm -qf /usr/lib64/libcrypt.so.2
libxcrypt-4.4.18-3.el9.aarch64
To compile/link a binary, you need the development package. When passing -lcrypt option to gcc/ld, the linker resolves to the share lib name pointed by libcrypt.so, limiting to the major version number. As result, depending on the OS where the binary is built, you get a dep to libcrypt.so.1 or libcrypt.so.2 ... and consequently, since esql also links binaries, there can be a difference between the libcrypt.so.? dependency of the provided Informix CSDK libs and the binary build by CSDK users, on their own platform.
I think that for now, we have to patch the esql script to get binaries dependent to libcrypt.so.1, like the libs of Informix CSDK that IBM/HCL provides, because you probably have libcrypt.so -> libcrypt.so.1 (or just libcrypt.so.1 -> whatever) on the machine where the CSDK libs are compiled/linked.
Once IBM/HCL provides a new CSDK with libs dependent to libcrypt.so.2, we can use esql on our system, without patching it.
Seb
------------------------------
Sebastien FLAESCH
------------------------------
Original Message:
Sent: Thu January 25, 2024 07:53 AM
From: Andreas Legner
Subject: Informix CSDL 4.50 on Linux ARM dependency to libcrypt.so.1 + building with esql => libcrypt.so.2
Also, on our systems (SLES 12.3) we happen to have:
# ll libcrypt*
-rwxr-xr-x 1 root root 57744 Jun 6 2017 libcrypt-2.22.so
-r-xr-xr-x 1 root root 2447744 Feb 6 2017 libcrypto.so.1.0.0
lrwxrwxrwx 1 root root 16 Jan 25 13:39 libcrypt.so.1 -> libcrypt-2.22.so
So both - seemingly - v1 + v2, but actually v2 only, and no libcrypt.so as such.
And an esql/c binary would have this in ldd:
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f10abe62000)
So how does -lcrypt decide this? Why did it go for v2 in your case? Would the compiler version play into this?
And I'd assume the -lcypt simply is passed to the linker and Informix / esql won't have any say in what is going to happen with it.
------------------------------
Andreas Legner
Original Message:
Sent: Fri January 19, 2024 05:01 AM
From: Sebastien FLAESCH
Subject: Informix CSDL 4.50 on Linux ARM dependency to libcrypt.so.1 + building with esql => libcrypt.so.2
Hello,
We have a Linux RedHat 9.2 ARM (aarch64) with CSDK 4.50.FC6 installed:
[f4gl@pisano lib]$ cat /etc/redhat-release
Red Hat Enterprise Linux release 9.2 (Plow)
[f4gl@pisano lib]$ uname -a
Linux pisano.strasbourg.4js.com 5.14.0-284.30.1.el9_2.aarch64 #1 SMP PREEMPT_DYNAMIC Fri Aug 25 10:57:12 EDT 2023 aarch64 aarch64 aarch64 GNU/Linux
[f4gl@pisano lib]$ esql -V
IBM Informix CSDK Version 4.50, IBM Informix-ESQL Version 4.50.FC6
It appears that the Informix client libs have a dependency to libcrypt.so.1:
[f4gl@pisano CSDK-4.50.FC6]$ ldd lib/cli/libifcli.so | grep libcrypt.so
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000ffffa56a3000)
However, on this system, we can see that there are 2 versions of libcrypt.so.? :
[f4gl@pisano lib]$ ls -l /usr/lib64/libcrypt.so*
lrwxrwxrwx. 1 root root 17 Aug 10 2021 /usr/lib64/libcrypt.so -> libcrypt.so.2.0.0
lrwxrwxrwx. 1 root root 17 Aug 10 2021 /usr/lib64/libcrypt.so.1 -> libcrypt.so.1.1.0
-rwxr-xr-x. 1 root root 201816 Aug 10 2021 /usr/lib64/libcrypt.so.1.1.0
lrwxrwxrwx. 1 root root 17 Aug 10 2021 /usr/lib64/libcrypt.so.2 -> libcrypt.so.2.0.0
-rwxr-xr-x. 1 root root 201632 Aug 10 2021 /usr/lib64/libcrypt.so.2.0.0
And as you can see, /usr/lib64/libcrypt.so is a symbolic link to libcrypt.so.2.
The esql tool uses the following libs to link the binary:
[f4gl@pisano lib]$ esql -libs
-lifsql
-lifasf
-lifgen
-lifos
-lifgls
-lpthread
-lm
-lz
-ldl
-lcrypt
/dbs/64bits/ifx/CSDK-4.50.FC6/lib/esql/checkapi.o
-lifglx
Consequently, when building a binary with esql, we'll get a dependency to libcrypt.so.2 ...
[f4gl@pisano tmp]$ esql -o xx.bin xx.ec
[f4gl@pisano tmp]$ ldd xx.bin
...
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x0000ffff8ca4b000)
...
Questions:
- Is it a problem to have the Informix libs loading libcrypt.so.1, and the binary load libcrypt.so.2 ?
- Is there a way (and good idea?) to force to link our binary with libcrypt.so.1 to be sync with Informix libs?
- Will there be a CSDK build with Informix libs dependent to libcrypt.so.2, assuming that's the recommended way to use a more recent libcrypt version?
- Assuming one can mix libcrypt.so.1 / libcrypt.so.2 at runtime (I have doubts!): What is the recommendation, when building a binary on this platform, and install the resulting binary on an equivalent Linux, that does not have libcrypt.so.2? It appears that some Linux distributions such as Ubuntu 22.04 do not provide a package for libcrypt.so.2 ...
Tx
------------------------------
Sebastien FLAESCH
------------------------------