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
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
/usr/lib/gcc/x86_64-redhat-linux
with
3.4.6 4.4.4 4.4.5 4.4.6
as 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
