IBM Data Management Community Connect with Db2, Informix, Netezza, open source, and other data experts to gain value from your data, share insights, and solve problems. Join / Log in
Just seen this workaround in Informix Server System Requirements
** Following system libraries are needed for IBM Informix Dynamic Server version 14.10.FC9 and greater to run on Red Hat Linux 9. Higher versions of same libraries are installed on Red Hat Linux 9. As a workaround, symbolic links to those libraries need to be created.
Libraries needed for IDS: libncurses.so.5 libtinfo.so.5 Libraries installed on Red Hat Linux 9: libncurses.so.6 libtinfo.so.6 Workaround: Run following commands as root user from /usr/lib64 directory. ln -s libncurses.so.6 libncurses.so.5
ln -s libtinfo.so.6 libtinfo.so.5
To me, it is a dangerous practice to create such symbolic links to fake the shared lib dependencies.
The shared library version is there for a good reason. Are you sure that this is 100% safe?
Is it not better to install the libncurses V5 package when it's available or, build an Informix IDS package that uses libncurses V6?
In fact, we have a similar issue here and I wonder how you ended up with this workaround...
Thanks for the update.
IMO, the correct solution would be to have a dedicated build of Informix IDS for RHEL 9, with the dependency to libncurses.so.6 and libtinfo.so.6.
This is what we plan for our product.
But wouldn't this mean having multiple different 'flavors' of the same Informix version, for RHEL9+, for RHEL8-, for ..., creating even more potential confusion ("which flavor of 14.10.FC10 would I use for my particular Linux distribution and version?!?")
Yes that's the dilemma: Have tailored IDS packages for any supported Linux platforms, or have less or one common package, with tricky workarounds to make it work on some Linux brands/versions.
I understand it's more work, but that's the idea of shared libs versioning and Linux package dependencies.
Here we ended up with platform codes in or package names (mainly with GLIBC version deps), for a given set of "compatible" Linux brands.
The biggest problem to my mind, is that even the latest of the ESQL/C libraries were built using GCCv5 or v6 and GCC is up to v11 or v12 with internal library changes and code migrating from one library to another since GCC v7. The GCC 5 libraries are no longer available and v6 are hard to find.