rebuilding glibc on RHEL, for /opt deployment

Hi,

I want to build a newer glibc for my company's internal distribution, on RHEL5&6. It would be installed in a separate location, so would only affect applications which choose to build with it, not yum installed binaries. However, is this safe for production usage? Ie. Can a vanilla upstream (or fedora srpm) built glibc be used with a RHEL kernel and root filesystem configuration?

In wondering if the RHEL or Fedora packaged glibc contains any required patches matching the kernel.

The only mention of upstream glibc userland incompatibilities that I've found is the 2.18-2.19 s390 jmp_buf issue, which was rolled back in 2.20.

Thanks!

buy RHEL 7.1 !!!!


you really can not use the the fedora 21 or 22 version of glibc in rhel5 or 6

it take it that redhat support already stated as much

if you try
you WILL !!!! null and VOID that $799 to over $9,000 per year your company is spending on the license

what dose your manager say ?

I would love to use RHEL7, but we're a diverse tech company and migration is slow. Multiple issues - teams on RHEL5 who don't want the disruption of a big move to RHEL6, and sysadmins who need to re-engineer all their scripts to use RHEL7's systemd.

What I'm looking for are the technical reasons why a (say) fedora 21 glibc might not work on a 3.17 RHEL kernel. All I hear are vague comments like "it's not recommended", but my use case is more restricted than upgrading the /usr/lib64/libc.so.

Presumably this applies equally to Docker, since RHEL7 supports docker and you could run Fedora 21 inside a RHEL7 host.

We're already building our own gcc & library toolchain, so we're not using the support contract for this

See glibc-howto from Linux Documentation Project.

When we build glibc from source we give a the oldest kernel version to be supported. So that the built glibc run correctly with that much oldest kernel.

But a newer kernel should not be run with this glibc because it might have some incompatibilities (ABI breakage). If you want, then whole glibc has to built with the headers from new kernel and plus may be glibc depending programs. So how come they upgrade kernel with keeping old glibc. What these Redhat guys do is they check changes with each kernel and glibc and only package if there is ABI breakage. There are kernel and glibc developers from Redhat and some of them are tasked with packaging kernel and glibc packages and other interdependent packages.

So best would be to make a separate toolchain plus packages using it.

Couple things:

1- You don't "buy RHEL 7.1". You buy generic RHEL entitlements and you can deploy whatever versions of RHEL are available.
2- The OP is asking about specific reasons why a version of glibc should not be used with a version of the kernel that it was not built for. The OP will not get answers to such a question, because answers for those questions do not exist. glibc is not tested under such conditions. Therefore, it's a huge unknown. Red Hat quarantees API and ABI compatibility within major versions. Outside of that, it's unsupported, untested and unwise. It is certainly not production-ready when you roll your own under such conditions.

Eventually, you will likely tire of the never-endingly large list of dependencies required to maintain these rogue versions of libraries. Alternately, you can consult the Red Hat Dev toolkit (RHDTS) and Red Hat Software Collections. They may have updated libraries and tools that will work for your org, and are supported for use. Perhaps those versions are close enough to what your developers are wanting to use in the field and you can compromise.

3-

What I'm looking for are the technical reasons why a (say) fedora 21 glibc might not work on a 3.17 RHEL kernel. All I hear are vague comments like "it's not recommended", but my use case is more restricted than upgrading the /usr/lib64/libc.so. Presumably this applies equally to Docker, since RHEL7 supports docker and you could run Fedora 21 inside a RHEL7 host.

See #2, above. There are no happy-fun answers to your questions. Also, even RHEL 7.1 isn't on 3.17, yet. Pretty sure that's 3.10.

As for your Docker question, no, I do not believe that's accurate. Docker doesn't have any kernel interaction, so the host OS kernel isn't aware of F21 userspace libs and bits that are running on it-that's the genius behind Docker.

Per Dan Walsh:

"THE KERNEL KNOWS SQUAT ABOUT CONTAINERS."

Actually it's the other way around. Docker containers only interact with the host kernel, and don't see the other parts of the host OS. They're kept separate with user namespaces & cgroups. Thus the container's glibc interacts with the host kernel, only.

An example of docker incompatibilities :
http://www.fewbytes.com/docker-selin...-indipendence/

Issues like this will help flush out kernel / glibc incompatibilities over the next few years I expect.

I'm surprised no one has listed technical examples of breakages. It sounds like a lot of hearsay so far. Veerain made a good point about glibc being compiled for a specific kernel even though it declares a minimum version, but gave no example of an actual ABI breakage that was avoided. The upstream GLIBC / kernel developers go to great efforts to avoid this, so it shouldn't be necessary in theory. However, this is is still important - a college of mine mentioned an example with clock_gettime on RHEL5 - using a 3.0 kernel on RHEL5 apparently degrades the performance of this critical function as the vDSO implementation changed since that GLIBC (2.0.5) was compiled (I haven't found sources for this yet); glibc provides compatibility when upgrading the kernel, but not performance guarantees.

Our devs ask for gcc 4.9 & clang 3.6 on the day of release, so devtoolset would only be part of the solution.

RHEL7 kernel is indeed 3.10. Our sysadmins must be using a newer one for some machines.

Thanks for all the replies!

That's not quite my understanding but that's not germane to the subject.

Whether it's hearsay or not, the strength of red hat and rhel is the support. If you're hacking in libraries and kernels to versions they do not belong, then you lose that support. At that rate, it's better to be rolling CentOS or something else for free.