1

I am seeing undefined symbols when trying to link shared libraries with a program on Redhat Linux.
We are running Linux kernel 3.10.0, gcc 4.8.2 with libc-2.17.so, and libblkid 2.23.2

When I build the application I am writing I get two undefined symbols from libblkid: memcpy@GLIBC_2.14 and secure_getenv@GLIBC_2.17. (A very similar build works on other machines, ostensibly using the same versions of everything).

Note, for secure_getenv libblkid wants the same version as the libc library itself.

Looking at the symbols defined in libc-2.17.so I find memcpy@@GLIBC_2.14, memcpy@GLIBC_2.2.5, secure_getenv, and secure_getenv@GLIBC_2.2.5. According to my understanding the double @ in the first memcpy version is simply supposed to mark it as the default version. And, for some reason even in this libc with versioned symbols the first secure_getenv appears to be unversioned.

So, why does a requirement for memcpy@GLIBC_2.14 not match the defaulted memcpy@@GLIBC_2.14?

And logically I would expect the base version of secure_getenv in libc-2.17 to match a requirement for version 2.17.

So, what is going on here? What is making it fail on my development machine and not others? How do I fix this? (As the make works on other machines this appears to be something specific to my build environment, but what?)

Ankur Aggarwal
  • 2,210
  • 2
  • 34
  • 39
S. Friesen
  • 11
  • 4
  • Show your link command. Are there any binaries you have not compiled yourself? Do you have anything in /usr/local/lib\*? – n. m. could be an AI Jan 25 '17 at 16:37
  • Here it is for real: @n.m The basic link line is cc -o myapp app_main.o file1.o file2.o file3.o -g --verbose -DDEBUG -fPIC -L/usr/lib/gcc -lgcc -L/usr/lib/x86_64-redhat-linux6E/lib64/ -lm -lpthread -Llib64 -Llib -lcommon -lcrypto -lssl -ldl -lblkid -lnv_env -lnv_io. liblzo2 is in /usr/local/lib Apparently libcommon, libcrypto and libssl are project level .a files. P.S. forgot to mention this is 64 bit Linux, and most libraries are in /usr/lib64. – S. Friesen Jan 25 '17 at 17:26
  • Anything that is not yours in `/usr/local/lib*`? Try to rearrange your libraries in dependency order .http://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause. You don't need things like -lggc or -L/usr/lib/x86_64-redhat-linux6E/lib64/, these are automatic by gcc. – n. m. could be an AI Jan 25 '17 at 18:03
  • Weird. Removing the excess -L options and -lgcc fixed it. Those were being added by a line in the makefile that checks if gcc is being used and adds those if it is _not_ being used. And since for some reason the compiler is being called as 'cc' instead of 'gcc' it invoked that branch. – S. Friesen Jan 25 '17 at 18:40

1 Answers1

-1

You probably have compat-glibc installed, as indicated by the -L/usr/lib/x86_64-redhat-linux6E/lib64 argument. compat-glibc on Red Hat Enterprise Linux 7 provides glibc 2.12 only, so it cannot be used to link against system libraries.

Florian Weimer
  • 32,022
  • 3
  • 48
  • 92