/lib/libc.so.6 and Peopletools 8.53

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 ?

Easy check:

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

Launching installer...

===============================================================================
PeopleTools                                      (created with InstallAnywhere)
-------------------------------------------------------------------------------

Preparing CONSOLE Mode Installation...

===============================================================================
Welcome
-------

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 ?

Nicolas.