RH 6.8 giving GLIBC_2.14 NOT FOUND
 

I am on a Linux RH 6.8 system.
I have an up to date glibc.
When I compile/run a C program on this system I get the following:
..GLIBC_2.14 not found..
How can the compile/run elements be out of sync for version on the same system?

Based on what you posted, there's no way we can even guess. Who wrote it? What are its dependencies? Is your system up to date?? If so, you must have access to the Red Hat network, since you're paying for RHEL. Have you contacted RHEL support?

Testing
 

Thanks for getting me to think of this in simpler terms.
This involves a C program that we build/access as a shared library.
I created/ran a basic "Hello World" C test program and it worked fine.
The problem is seen when we access a C library (that we build) from a Java program via a JNA interface.
I'll take this over to a JNA forum.
Thanks,

i doubt GLIBC_2.14 is the current version

the current libc6 you do have may or may not have all GLIBC_2.14 symbols mapped in it

(if not, then there are ways to install and use previous libc6)

for example, libcairo compiled for libc6-2.3 has this:

Version References:
required from libpng14.so.14:
0x052a4a70 0x00 05 PNG14_0
required from libc.so.6:
0x09691f73 0x00 13 GLIBC_2.1.3
0x0d696913 0x00 10 GLIBC_2.3
0x09691974 0x00 09 GLIBC_2.3.4
0x06969191 0x00 08 GLIBC_2.11
0x0d696910 0x00 07 GLIBC_2.0
0x0d696912 0x00 06 GLIBC_2.2
0x0d696911 0x00 04 GLIBC_2.1
required from libpthread.so.0:
0x0d696911 0x00 12 GLIBC_2.1
0x0d696910 0x00 03 GLIBC_2.0
required from libm.so.6:
0x0d696911 0x00 11 GLIBC_2.1
0x0d696910 0x00 02 GLIBC_2.0

the reason these GLIBC_XX symbols are supported by libc6 is because of "redhat technology". other linux distros use it.

there is an issue that it's "possible" that a mapped symbol for compatibility isn't actually compatible (due to changes). but those are known as bugs and hopefully fixed.

your version of libc6 is likely higher than 2.3, and likely supports everything back to 2.0 with some exceptions


next note it may not be redhat's system that causes the message: it could be old libraries or old binaries in your own software which would be helped to (find the symbols/not complain) if they were re-compiled using redhat system your running.

the above list was seen using:

$ objdump -a -x -S -D "$1" | less

# $1 was libcairo.so.2 in this case