GCC静态库链接VS动态链接 [英] gcc static library linking vs dynamic linking
问题描述
我的编译环境为的CentOS 5 。我有一个名为libcunit第三方库。我用自动工具安装了它,它会产生两种 libcunit.a
和 libcunit.so
。我有我自己的应用程序,与一群共享库的链接。 libcunit.a
是在当前目录和 libcunit.so
和其他共享库在在/ usr / local / lib目录/
。当我编译如下:
的gcc -o测试test.c的-L。 libcunit.a -L在/ usr / local / lib目录-labc -lyz
我得到一个链接错误:
libcunit.a(Util.o):在功能`CU_trim_left:
。Util.c :(文字+ 0x346):未定义的参考`__ctype_b
libcunit.a(Util.o):在功能`CU_trim_right:
。Util.c :(文字+ 0x3fd):未定义的参考`__ctype_b
但是,当我与的.so
编译如下:
的gcc -o测试test.c的-L在/ usr / local / lib目录-lcunit -labc -lyz
它编译罚款和运行正常了。
与 libcunit.a
?
与
静态链接时,为什么给错误libcunit.a
块引用>问题是,你的
libcunit.a
建一个古老的Linux系统上,并取决于已符号的删除的从的libc
(这些符号在的glibc-2.2
使用,并且从的glibc-2.3 被拆除code> 10年前)。更确切地说,这些符号已
隐藏
。他们是动态链接到老的二进制文件(如libcunit.so
),但没有新的code提供可静态链接到它们(您不能创建一个新的引用他们的可执行文件或共享库)。您可以像这样观察此:
readelf -ws /lib/x86_64-linux-gnu/libc.so.6 | egrep的'\\ W__ctype_b \\ W'
769:00000000003b9130 8 OBJECT全局默认31 __ctype_b@GLIBC_2.2.5readelf -ws /usr/lib/x86_64-linux-gnu/libc.a | egrep的'\\ W__ctype_b \\ W'
#没有输出My build environment is CentOS 5. I have a third party library called libcunit. I installed it with autotools and it generates both
libcunit.a
andlibcunit.so
. I have my own application that links with a bunch of shared libraries.libcunit.a
is in the current directory andlibcunit.so
and other shared libraries are in/usr/local/lib/
. When I compile like:gcc -o test test.c -L. libcunit.a -L/usr/local/lib -labc -lyz
I get a linkage error:
libcunit.a(Util.o): In function `CU_trim_left': Util.c:(.text+0x346): undefined reference to `__ctype_b' libcunit.a(Util.o): In function `CU_trim_right': Util.c:(.text+0x3fd): undefined reference to `__ctype_b'
But when I compile with
.so
like:gcc -o test test.c -L/usr/local/lib -lcunit -labc -lyz
it compiles fine and runs fine too.
Why is it giving error when linked statically with
libcunit.a
?解决方案Why is it giving error when linked statically with
libcunit.a
The problem is that your
libcunit.a
was built on an ancient Linux system, and depends on symbols which have been removed fromlibc
(these symbols were used inglibc-2.2
, and were removed fromglibc-2.3
over 10 years ago). More exactly, these symbols have beenhidden
. They are made available for dynamic linking to old binaries (such aslibcunit.so
) but no new code can statically link to them (you can't create a new executable or shared library that references them).You can observe this like so:
readelf -Ws /lib/x86_64-linux-gnu/libc.so.6 | egrep '\W__ctype_b\W' 769: 00000000003b9130 8 OBJECT GLOBAL DEFAULT 31 __ctype_b@GLIBC_2.2.5 readelf -Ws /usr/lib/x86_64-linux-gnu/libc.a | egrep '\W__ctype_b\W' # no output
这篇关于GCC静态库链接VS动态链接的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!