There was a recurrent “issue” when installing Peopletools 8.5x on Oracle Linux 6.x. As I wrote here about Tuxedo install with Peopletools 8.50 on OL6.0, and here for Peopletools 8.52 install on OL 6.3, each time the installer complained about strings: '/lib/libc.so.6': No such file.
As far as I know, that was just an other annoying message that we can ignore, even though rather questionable. It did not make anything wrong to leave this as is.
What about Peopletools 8.53 installer ?
1. Status of my server. As expected, the file /lib/libc.so.6 does not exists:
[psoft@orion6 lib]$ more /etc/redhat-release
Red Hat Enterprise Linux Server release 6.4 (Santiago)
[psoft@orion6 lib]$ ls /lib
alsa cpp crda firmware kbd lsb modules security terminfo udev
2. Let’s install the Peopletools 8.53:
[psoft@orion6 lib]$ cd /nfs/software/PeopleSoftCD/PeopleTools/PT8.53/PeopleTools8.53.00/Disk1
[psoft@orion6 Disk1]$ ./setup.sh
Setting temporary directory /tmp/IA.26003
Executing setup.linux -DCOMP_NAME=orion6.phoenix.nga -DPS_UMASK=0002
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
PeopleTools (created with InstallAnywhere)
Preparing CONSOLE Mode Installation...
InstallAnywhere will guide you through the installation of PeopleTools 8.53.
PRESS <ENTER> TO CONTINUE:
=> No error is returned…
3. So, since the file is not on OS level, something should have been changed in setup.linux (this file is used by the installer on Linux). Let’s check the libc file checking as I did in my previous article mentioned above:
[psoft@orion6 Disk1]$ cd /InstData
[psoft@orion6 InstData]$ ls
emocmutl.jar jlib Resource1.zip setup.exe setup.linux setup.solaris-x86_64
emocmutl.zip MediaId.properties setup.aix setup.hp-ia64 setup.solaris setup.zlinux
[psoft@orion6 InstData]$ grep -B 3 -A 2 libc setup.linux
# LD_ASSUME_KERNEL for Native POSIX Threading Library on some Linux distros
#if [ `uname` = "Linux" -a -n "`which strings 2>/dev/null`" ]; then
# debugOut "checking for NPTL + JVM vulernability..."
#check libc to see if it was compiled with NPTL
# nptl="`strings /lib/libc.so.6 | grep -i nptl`"
# if [ "$nptl" ]; then
# debugOut "NPTL detected! checking for vulnerable JVM....";
=> Surprisingly the line containing the file checking has just been commented out (and all the dependant lines as well).
What a workaround !
This is exactly why executable file keep growing over the years and versions, and code not being understandable by future developers who are themselves afraid to touch it.
Perhaps be clean and remove these lines would be much nicer, wouldn’t it ?