SCIENTIFIC-LINUX-USERS Archives

July 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Patrick J. LoPresti" <[log in to unmask]>
Reply To:
Patrick J. LoPresti
Date:
Wed, 9 Jul 2014 08:31:08 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
On Tue, Jul 8, 2014 at 11:58 PM, Yasha Karant <[log in to unmask]> wrote:
> 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?

Your question is confused. The kernel is not "built against" glibc;
quite the opposite, in fact. By design, the kernel is completely
independent of glibc.

That said, if your application needs a newer glibc, you can either
take Pat's suggestion and try the devtoolset, or you can simply:

 - copy a newer libc.so.6 into /path/to/lib/
 - set the LD_LIBRARY_PATH environment variable to /path/to/lib
 - run the application

In my experience, there is a decent chance this will "just work",
depending on just how ancient your system is... You may find this
exposes other dependencies (libm, libpthread, etc). If so, you can add
them to /path/to/lib/. If and when that gets too annoying, you can
figure out how to use the devtoolset.

 - Pat

ATOM RSS1 RSS2