上下文:我不确定这是我的问题还是运行该程序的服务器的问题。我正在尝试编译并运行一个小实用程序,以成为一个使用 mysql 库的 cron 作业。该程序使用以下命令成功编译,没有错误或警告:
gcc my_program.c -o my_program -I /usr/include/mysql/ -L/usr/include/mysql -lmysqlclient -lglib-2.0 -Wall
我添加了 -lglib-2.0
因为...
问题: 当我尝试运行该程序时,它中止并出现以下错误:
./my_program: symbol lookup error: /usr/lib/libmysqlclient.so.15: undefined symbol: strcpy, version GLIBC_2.0
错误发生在运行时,在以下行中:
conn = mysql_init(conn);
conn
被声明为MYSQL *conn;
,这是我第一次使用mysql中的任何内容.h(声明除外),如果我在 my_program.c
本身中使用它,则 strcpy
可以正常工作。
从 libmysqlclient.so.15
链接的库是:
ldd /usr/lib/libmysqlclient.so.15
linux-gate.so.1 => (0xb7ef6000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7cf4000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7cc2000)
libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7ca9000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7c84000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7c6f000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b20000)
/lib/ld-linux.so.2 (0xb7ef7000)
我可以在代码中做些什么吗?我的编译或链接参数是否缺少某些内容,或者 的动态链接是否存在问题>libmysqlclient.so.15
库位于库本身内吗?如果是后者(我认为考虑到 mysql 库在服务器的其他地方使用,据我所知),服务器的管理员可以做什么来解决这个问题?
Context: I am not certain whether this is my problem or the problem of the server this is running on. I am trying to compile and run a small utility, to become a cron job, that uses the mysql libraries. The program compiles successfully with the following command, no errors or warnings:
gcc my_program.c -o my_program -I /usr/include/mysql/ -L/usr/include/mysql -lmysqlclient -lglib-2.0 -Wall
I added -lglib-2.0
because...
Problem: when I then try to run the program, it aborts with the following error:
./my_program: symbol lookup error: /usr/lib/libmysqlclient.so.15: undefined symbol: strcpy, version GLIBC_2.0
The error happens at runtime, in the following line:
conn = mysql_init(conn);
conn
is declared as MYSQL *conn;
, this is the first time I use anything from mysql.h (except for the declarations), and strcpy
works fine if I use it in my_program.c
itself.
The libraries linked from libmysqlclient.so.15
are:
ldd /usr/lib/libmysqlclient.so.15
linux-gate.so.1 => (0xb7ef6000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7cf4000)
libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7cc2000)
libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7ca9000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7c84000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7c6f000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b20000)
/lib/ld-linux.so.2 (0xb7ef7000)
Is there anything I can do in my code, are my compilation or linking parameters missing something, or is there a problem with the dynamic linking of the libmysqlclient.so.15
library that lies within the library itself? If the latter (which I don't think considering that the mysql library is used in other places in the server AFAIK), what can the server's admin do to fix the problem?
发布评论
评论(2)
尝试将
-rdynamic
标志传递给gcc
。因为我不应该淹没评论部分:
GLIBC_2.0
是在libc.so.6
中定义的宏。因此,在您的系统上,libc.so.6
是 GNU 的 C 库实现。如果您仍然遇到问题,则很可能
libmysqlclient.so.15
是针对不同版本的libc.so.6
构建的,并且需要不同的符号。在这种情况下,您可能必须从源代码重建libmysqlclient.so
以链接到系统上的库,或者查看是否有适用于您的平台的升级版本。Try passing the
-rdynamic
flag togcc
.Since I shouldn't flood the comment section:
GLIBC_2.0
is a macro that is defined inlibc.so.6
. So on your system,libc.so.6
is GNU's C library implementation.If you are still running into problems it's very possible that
libmysqlclient.so.15
was built against a different version oflibc.so.6
and expects different symbols. In that case you may have to rebuildlibmysqlclient.so
from source to link with the libraries on the system, or see if there is an upgraded version available for your platform.抱歉,我发现了问题。实际上这不是符号查找错误,而是分段错误。因为我使用未初始化的 conn 而不是 NULL 来调用 mysql_init 来进行初始化,所以 libmysqlclient 一定已经崩溃并且,由于超出我有限的 C 知识范围的原因,产生了错误的错误消息。
在具有相同操作系统的不同版本的另一个系统上进行调试会产生正确的错误,这更容易调试。
My apologies, I found the problem. It was not in fact a symbol lookup error, but a Segmentation Fault. Because I had called
mysql_init
with an uninitializedconn
instead ofNULL
for the initialization,libmysqlclient
must have broken down and, for reasons beyond my limited knowledge of C, produced the wrong error message.Debugging on another system with a different build of the same OS produced the correct error, which was a lot easier to debug.