On 07/09/2014 06:22 AM, Pat Riehecky wrote:
> On 07/09/2014 01:58 AM, Yasha Karant wrote:
>> An end user using a pre-compiled package has run into an issue.  The 
>> package requires glibc 2.15, such as glibc-2.15-60.el6.x86_64.rpm 
>> that is available from sourceforge.
>>
>> Unfortunately, the kernel used on this machine has been modified for 
>> specific special drivers and configurations.  Assuming that the 
>> kernel has not been built against glibc 2.15, is there any relatively 
>> simple way to allow the user application to use the required glibc 
>> but to keep the kernel and related systems binary programs on the 
>> glibc against which the kernel was built?
>>
>> If this inconsistency for the application program causes the end user 
>> application to crash, we will need to rethink our strategy -- but 
>> first we want to try the simplest solution.  We do not plan to 
>> rebuild the kernel as the system will move to SL 7 as soon as it goes 
>> to production status (presumably within a week or two) -- we have two 
>> new 4 Tbyte enterprise-rated systems drives that will be used for the 
>> SL 7 transition.
>>
>> Yasha Karant
>
> The devtoolset repos feature a newer glibc that can be used for these 
> sorts of purposes.
>
> http://ftp.scientificlinux.org/linux/scientific/6x/external_products/devtoolset/ 
>
>
> Please be sure to review the README and associated documentation.
>
> Pat
>
APOLOGIES:  the path for the /usr/lib/gcc/x86_64-redhat-linux that I 
posted was incorrect for the matter of using a later glibc; a corrected 
posting is below.

In clarification of what I posted, here is a quote from a different 
thread that concerns EL (and linux in general), not from me:

No, the solution is to recompile the app to use GLIBC 2.5 and then it 
will run on 2.5, 2.6 and 2.7. Updating glibc to 2.7 on Centos is just 
asking to break the entire machine. Hint: glibc is the C runtime and is 
used by just about everything.

End quote.

As of now, I do not have the option of recompiling the enduser application.

I have looked for the appropriate glibc in the devtoolset, but this does 
not seem to be there; I did a "full install" so that the machine now has
  /opt/rh/devtoolset-2 with various parts under this path
(such as

/opt/rh/devtoolset-2/root/usr/lib/gcc/x86_64-redhat-linux/4.8.2

and directories thereunder)

I do see

/opt/rh/devtoolset-2/enable

as a configuration file (presumably for endusers as well) that contains 
path configuration statements such as:

export PATH=/opt/rh/devtoolset-2/root/usr/bin${PATH:+:${PATH}}
export MANPATH=/opt/rh/devtoolset-2/root/usr/share/man:$MANPATH
export 
INFOPATH=/opt/rh/devtoolset-2/root/usr/share/info${INFOPATH:+:${INFOPATH}}

export 
LD_LIBRARY_PATH=/opt/rh/devtoolset-2/root$rpmlibdir$rpmlibdir32${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

and the like

I also tried:

rpm --prefix=/opt/rh -Uhv glibc-2.15-60.el6.x86_64.rpm
warning: glibc-2.15-60.el6.x86_64.rpm: Header V4 RSA/SHA1 Signature, key 
ID ea675ea0: NOKEY
error: package glibc is not relocatable

Note that the enduser packages are compiled for 64 bit X86-64, not 32 
bit IA-32.

Any suggestions as to how to proceed?

Yasha Karant