Glibc Sources?

Home » CentOS » Glibc Sources?
CentOS 17 Comments


Please excuse any ignorance in this e-mail as I am not a RH/CentOS/Fedora user and may blunder my way through the correct terminology for my request.

I’m tasked with reconstructing the CentOS version of the GlibC library for testing with gethostbyname(). My mission is to show that we are not affected by the latest exploit for the product we are shipping targeted for RHEL and CentOS. To do so, I want to equip gethostbyname() with additional code.

My objective is to rebuild from source the EXACT version of GlibC for CentOS 6.6. Afterwards, I will make my changes in the code, rebuild and complete my testing. reports:
GNU C Library stable release version 2.12, by Roland McGrath et al. Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-11). Compiled on a Linux 2.6.32 system on 2015-01-27. Available extensions:
The C stubs add-on version 2.1.2.
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
RT using linux kernel aio libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:

But, when looking through the source code for this version on the CentOS servers I only see:

[ ] glibc-2.12-1.149.el6_6.4.src.rpm 07-Jan-2015 22:45 15M
[ ] glibc-2.12-1.149.el6_6.5.src.rpm 27-Jan-2015 23:13 15M

Please point me to the correct source tarball, and all required patches so that I can reconstruct my loaded version of GlibC. A yum command is also acceptable.

Thanks, Andy

17 thoughts on - Glibc Sources?

  • This is the latest version for a fully patched CentOS 6 system.

    % rpm -q glibc

  • Hi Andy,

    You can use yumdownloader to download the source

    $ yumdownloader –source glibc

    $ rpm -ivh This will give you all the relevant files required for building the package.

  • No problem.

    Do you plan on shipping this updated glibc as part of the product, or is this simply for testing? If you plan to distribute/ship an updated glibc, that’s probably going to raise a few eyebrows and anger a few sysadmins.

    Those src.rpms contain the source and the patches. You may want to read over for info.

  • ​I may be way out of line here, haven’t had much coffee yet, but I wonder if systemtap could be used to achieve your goals less intrusively?​

  • No release. Only testing.

    Great! Thank you Jim Perrin, Frank Cox, Earl A Ramirez and Stphen Harris for your responses.


  • Already knowing how to build GlibC, I think that may take less of my time than attempting to figure out how to use systemtap. But, you better believe that I’ll keep that in mind ::throws in toolbox:: for later. This one I need to be as fast as possible on.

    Thanks for the info!


  • Also, please be advised that rebuilding a package and then trying to compare it to something else built earlier is likely not going to work unless you can duplicate the exact set of packages that are installed in the build root at the time of the build. Even then, with documentation generation, you STILL might not get an exact, bit for bit, match when building later.

    It is almost impossible to duplicate a closed and staged build system for a give date unless you are trying very hard to do so.

    ^^ That would likely be impossible to accomplish. See my comments above.

    Thanks, Johnny Hughes

  • The list of packages that were in the “mock build root” for our build of the glibc-2.12-1.149.el6_6.5.x86_64.src.rpm is here:

    To get close to an exact match, you need to use mock and use the packages listed above (and only those versions) if you are trying to get a build that matches what we built.

  • Okay, thanks. I really don’t need _EXACT_ match, but close. Again, my aim is to equip GlibC with some logging facilities IF anyone is using the gethostbyname(). Given the help from this list, I was able to rebuild GlibC for CentOS and am testing my stuff now.

    I appreciate your help on this matter. Not knowing where the knobs are was the hardest part. I have just about completed my testing.

    Again, thanks for the help!


  • Ughh!! I just realized that the app that I’m testing has parts that are linked against 32-Bit libraries. I have to test that as well. Ouch!

    This leads to the question:

    How do I tell rpmbuild to build the i686 version of the library in place of the x86_64? I’ve done some looking around on the web and I have found something about:

    setarch i686 mock -r … rebuild

    Not being able to find the “mock” package for CentOS, I thought maybe:

    setarch i686 rpmbuild -ba glibc.spec

    would work. This ended with an error:

    enable-bind-now –with-tls –with-__thread –build i686-redhat-linux –host i686-redhat-linux –enable-multi-arch –enable-systemtap –disable-profile –enable-experimental-malloc –enable-nss-crypt checking build system type… i686-redhat-linux-gnu checking host system type… i686-redhat-linux-gnu checking for i686-redhat-linux-gcc… gcc checking for suffix of object files… configure: error: in `/home/akennedy/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-i686-linuxnptl’:
    configure: error: cannot compute suffix of object files: cannot compile See `config.log’ for more details. error: Bad exit status from /var/tmp/rpm-tmp.2d2i9G (%build)

    I have also looked through the glibc.spec file for something that would make me think that I could change the target variant.

    “rpmbuild –target=i686 -ba glibc.spec” gives the same output as the setarch i686 above.

    Again, any help on this would be greatly appreciated.

    Thanks, Andy

  • ??? Mock is in EPEL.

    If you repackaged the source rpm you should be able to:
    mock -r epel-6-i386 –rebuild glibc-xxx.srpm

  • Hi Andy,

    mock is part of EPEL and is almost certainly what you want to use.

    Kahlil (Kal) Hodgson GPG: C9A02289
    Head of Technology (m) +61 (0) 4 2573 0382
    DealMax Pty Ltd GitHub: @tartansandal

    Suite 1416
    401 Docklands Drive Docklands VIC 3008 Australia

    “All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer.” — IBM maintenance manual, 1925

  • De-ignorant me please: How does one discern the package name “EPEL” from mock?

    I tried everything I could think of (keeping in mind that I’ve been a Slackware fan since
    1993 or so) from “yum provides */mock” to various other commands that were as equally useless to me. Google wasn’t even my friend — though I did find the Fedora mock developer’s page — but I read something else that says that one cannot use Fedora packages within CentOS without resolving too many dependencies.

    Just a little light will do. . . I’ve felt my way around in the CentOS dark so far without too many cuts.

    Thanks, Andy