使用版本化符号（memcpy＆secure_getenv）链接失败
尝试将共享库链接到Redhat Linux上的程序时，出现未定义的符号。
我们的Linux内核是3.10.0，与libc-2.17.so GCC 4.8.2，并且libblkid 2.23.2使用版本化符号（memcpy＆secure_getenv）链接失败
当我建立我写的应用程序，我得到两个未定义的符号从libblkid：[email protected]_2.14和[email protected]_2.17 。 （一个非常类似的构建在其他机器上工作，表面上使用相同版本的一切）。
请注意，对于secure_getenv libblkid需要与libc库本身相同的版本。
查看libc-2.17.so中定义的符号，我找到[email protected]@GLIBC_2.14,[email protected]_2.2.5,secure_getenv和[email protected]_2.2.5。根据我的理解，第一个memcpy版本中的双重@只是简单地将其标记为默认版本。而且，由于某些原因，即使在这个版本符号的libc中，第一个secure_getenv看起来是未版本控制的。
那么，为什么[email protected]_2.14的要求不符合默认的[email protected]@GLIBC_2.14？
从逻辑上讲，我期望libc-2.17中的secure_getenv的基本版本与版本2.17的要求相匹配。
那么，这里发生了什么？什么使它在我的开发机器上失败而不是其他问题？我该如何解决？ （由于制造在其他机器上工作，这似乎是我的编译环境特定的东西，但是什么？）
您可能已安装compat-glibc，如-L/usr/lib/x86_64-redhat-linux6E/lib64参数所示。 Red Hat Enterprise Linux 7上的compat-glibc仅提供glibc 2.12，因此不能用于链接系统库。
显示您的链接命令。有没有你自己编译的二进制文件？/usr/local/lib \ *中有任何内容吗？ –
这是真实的： @ nm基本链接行是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位于/ usr/local/lib中 显然，libcommon，libcrypto和libssl是项目级别的.a文件。 P.S.忘了提及这是64位Linux，并且大多数库都在/ usr/lib64中。 –
任何不在'/ usr/local/lib *'中的东西？尝试按照依赖顺序重新排列库.http：//stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause。你不需要像-lggc或-L/usr/lib/x86_64-redhat-linux6E/lib64 /之类的东西，这些都是由gcc自动完成的。 –