简体   繁体   English

Ucc上的gcc未定义引用错误

[英]gcc undefined reference error on Ubuntu

I have a strange problem and i have gone through all similar questions but can't find an answer. 我有一个奇怪的问题,我已经经历了所有类似的问题,但无法找到答案。

I am trying to compile some code which keeps throwing up undefined reference error even though the library is specified using -l and is in the LD_LIBRARY_PATH too. 我正在尝试编译一些代码,这些代码不断引发未定义的引用错误,即使使用-l指定库并且也在LD_LIBRARY_PATH中。 I can't figure out the reason. 我无法弄清楚原因。 Here is an example 这是一个例子

gcc -L/home/sam/gmdb/lib -L/home/sam/db/add-ons/lib -L/home/sam/convert/lib -L/home/sam/rtana/lib -L/home/sam/rtana/add-ons/lib -o /home/sam/gmdb/bin/server /home/sam/db/obj/tools/server/server.o /home/sam/db/obj/tools/common/tool_data_parse.o /home/sam/db/obj/tools/common/tool_param.o /home/sam/gmdb/obj/tools/common/tool_public.o -lgmcommon -L/home/sam/db/add-ons/vpp/lib/suse -lipsi_crypto -lipsi_osal -lipsi_pse -lipsi_ssl -lgmmd5 -lgmkernel -lgmpl -lgmrep -lgmsqlserver -lgmsqlclient -lconvert -lrtana -lglog -lgflags -lprotobuf -lre2 -lboost_timer -lnuma -lpthread -lm -lrt gcc -L / home / sam / gmdb / lib -L ​​/ home / sam / db / add-ons / lib -L ​​/ home / sam / convert / lib -L ​​/ home / sam / rtana / lib -L ​​/ home / sam / rtana / add-ons / lib -o / home / sam / gmdb / bin / server /home/sam/db/obj/tools/server/server.o / home / sam / db / obj / tools / common / tool_data_parse.o /home/sam/db/obj/tools/common/tool_param.o /home/sam/gmdb/obj/tools/common/tool_public.o -lgmcommon -L / home / sam / db / add-ons / vpp / lib / suse -lipsi_crypto -lipsi_osal -lipsi_pse -lipsi_ssl -lgmmd5 -lgmkernel -lgmpl -lgmrep -lgmsqlserver -lgmsqlclient -lconvert -lrtana -lglog -lgflags -lprotobuf -lre2 -lboost_timer -lnuma -lpthread -lm -lrt

The list of undefined errors is long but the first one is 未定义错误的列表很长,但第一个是

/home/usama/convert/lib/libconvert.so: undefined reference to `numa_num_configured_cpus' /home/usama/convert/lib/libconvert.so:未定义的引用`numa_num_configured_cpus'

So as you can see it's complaining about a method in libnuma. 所以你可以看到它抱怨libnuma中的方法。 libnuma is provided a -lnuma as you can see, and is present in /usr/lib 如您所见,libnuma提供了一个-lnuma,并且存在于/ usr / lib中

The error mentions libconvert which is just a shared library that has a call to numa_num_configured_cpus but is not linked with libnuma, and it shouldn't matter since libconvert is just an so file. 该错误提到了libconvert,它只是一个调用numa_num_configured_cpus但没有与libnuma链接的共享库,因为libconvert只是一个so文件,所以无关紧要。 I am providing the -lnuma while generating the executable as you can see above. 我正在生成可执行文件时提供-lnuma,如上所示。 Here is the nm out on libconvert 这是关于libconvert的nm

nm -C -u convert/lib/libconvert.so | grep numa*
                 U google::protobuf::internal::NameOfEnum(google::protobuf::EnumDescriptor const*, int)
                 U numa_num_configured_cpus
                 U numa_num_configured_nodes

I did try to compile with --unresolved-symbols, which results in successful compilation but the binary doesn't run again complaining about undefined symbols. 我确实尝试使用--unresolved-symbols进行编译,这导致编译成功但二进制​​文件不会再次运行抱怨未定义的符号。

My GCC version is 我的GCC版本是

gcc --version
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And Ubuntu is 64 bit Ubuntu 12.10 Ubuntu是64位Ubuntu 12.10

Does anyone have a clue if i am hitting a bug or what is going on? 有没有人知道如果我遇到一个错误或发生了什么?

Guys thank you for your comments. 伙计们,感谢您的评论。 The problem as i found that is because the default behavior of gcc is changed in Ubuntu (at-least the version i am using) The hint is on this wiki page of debian https://wiki.debian.org/ToolChain/DSOLinking 我发现的问题是因为在Ubuntu中更改了gcc的默认行为(至少是我正在使用的版本)该提示位于debian的这个维基页面上https://wiki.debian.org/ToolChain/DSOLinking

According to this the gcc is changed to add --as-needed to the linker. 根据这个,gcc被更改为添加--as-needed到链接器。 The down side of this behavior is that and i quote the wiki " Binaries, which are using symbols from an indirectly linked shared library will fail to link " 这种行为的缺点是,我引用维基“二进制文件,它使用来自间接链接的共享库的符号将无法链接”

This was exactly the problem with me, as libconvert was using libnuma, but not linked to it, and the binary i was building tried to link everything including both libconvert and libnuma to it. 这正是我的问题,因为libconvert正在使用libnuma,但没有链接到它,而我正在构建的二进制文件试图链接包括libconvert和libnuma在内的所有内容。 The default gcc would work because it uses no-as-needed behavior which is changed in Debian and made it to Ubuntu as well. 默认的gcc会起作用,因为它使用了不需要的行为,这种行为在Debian中被更改并且也被用于Ubuntu。

So in short the linking works if i add -Wl,--no-as-needed . 因此,简而言之,如果我添加-Wl,--no-as-needed添加链接。

gcc -Wl,--no-as-needed -L/home/sam/gmdb/lib -L/home/sam/db/add-ons/lib -L/home/sam/convert/lib -L/home/sam/rtana/lib -L/home/sam/rtana/add-ons/lib -o /home/sam/gmdb/bin/server /home/sam/db/obj/tools/server/server.o /home/sam/db/obj/tools/common/tool_data_parse.o /home/sam/db/obj/tools/common/tool_param.o /home/sam/gmdb/obj/tools/common/tool_public.o -lgmcommon -L/home/sam/db/add-ons/vpp/lib/suse -lipsi_crypto -lipsi_osal -lipsi_pse -lipsi_ssl -lgmmd5 -lgmkernel -lgmpl -lgmrep -lgmsqlserver -lgmsqlclient -lconvert -lrtana -lglog -lgflags -lprotobuf -lre2 -lboost_timer -lnuma -lpthread -lm -lrt gcc -Wl, - no-as-needed -L / home / sam / gmdb / lib -L ​​/ home / sam / db / add-ons / lib -L ​​/ home / sam / convert / lib -L ​​/ home / sam / rtana / lib -L ​​/ home / sam / rtana / add-ons / lib -o / home / sam / gmdb / bin / server /home/sam/db/obj/tools/server/server.o / home / sam / db / obj / tools / common / tool_data_parse.o /home/sam/db/obj/tools/common/tool_param.o /home/sam/gmdb/obj/tools/common/tool_public.o -lgmcommon -L / home / sam / db / add-ons / vpp / lib / suse -lipsi_crypto -lipsi_osal -lipsi_pse -lipsi_ssl -lgmmd5 -lgmkernel -lgmpl -lgmrep -lgmsqlserver -lgmsqlclient -lconvert -lrtana -lglog -lgflags -lprotobuf -lre2 -lboost_timer - lnuma -lpthread -lm -lrt

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM