Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

This question already has an answer here:

We're running RHEL6, which only officially supports glibc 2.12. A user is requesting that we install a newer version.

I grabbed 2.18 from http://ftp.gnu.org/gnu/glibc/ and had no trouble running configure/make.

However when I attempt a small program to test it, I don't get the desired result:

test.c

#include <stdio.h>
#include </scratch/new-glibc-testing/include/gnu/libc-version.h>
int main (void) { puts (gnu_get_libc_version ()); return 0; }

I then compile and run with:

gcc test.c
./a.out

And the output I get is:

2.12

when I was hoping to get:

2.18

I also tried:

gcc -I/scratch/new-glibc-testing/include test.c

and changed the define line to:

#include <gnu/libc-version.h>

which compiles, but gives the same result (2.12).

I tried also using -nostdlib, ex:

gcc -nostdlib -I/scratch/new-glibc-testing test.c

This, however, throws errors:

/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400144
/tmp/cc6x03Do.o: In function `main':
test.c:(.text+0x5): undefined reference to `gnu_get_libc_version'
test.c:(.text+0xd): undefined reference to `puts'
collect2: ld returned 1 exit status

gcc --version results in: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

share|improve this question

marked as duplicate by slm, jasonwryan, terdon, Anthon, Zelda Jan 10 at 6:53

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
I'd suggest you install a VM for the user if he/she wants a newer glibc. It's a crucial part of any Linux OS and you risk hosing your whole system. –  schaiba Jan 10 at 0:01
1  
chroot or lx container will do, no need for a full vm in this case. –  oakad Jan 10 at 0:31

1 Answer 1

You need to specify the link path as well (-L -l) flags - only specifying the includes is not enough (in fact, you're risking application crashes when using headers from one version and libraries from a different one). You may also need -rpath and -rpath-link options passed to the linker, depending on your setup.

As mentioned in comments, it is rather difficult and dangerous to maintain multiple versions of the glibc in the same machine image. A safer approach is to setup a "slim" container (such as chroot jail or using lx) and to install a different system image into it with libraries updated as required.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.