尽管名称存在，静态链接失败
我正在尝试链接到静态库 libcovis.a。一切看起来都很好，但我仍然有
未定义对“CoViG_PublicDemo::MoInS::reset()”的引用
我检查了该名称是否存在于库中
$nm libcovis.a | grep 重置
...
_ZN16CoViG_PublicDemo5MoInS5resetEv
...
我正在使用链接参数 -L/path/to/libcovis.a -lcovis
我做错了什么？
编辑： 如果这样做的话，错误可能是其他原因
gcc main.cpp -I/usr/include/opencv -I/usr/include/cairo -I../../Source -o slam -rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext - lglut -lXi -lxml2 -lboost_文件系统-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo ../../Source/libcovis.a ../../Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
它有效！
但是当我在 KDevelop 中使用 cmake 时，我就不再工作了。我用
CMAKE_EXE_LINKER_FLAGS:STRING=-rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo /usr/local/src/CoViS-0.0.0-1/Source/libcovis.a /usr/local/src/CoViS-0.0.0-1/Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2psCMAKE_CXX_FLAGS:STRING=-I/usr/local/src/CoViS-0.0.0-1/Source -I/usr/include/opencv -I/usr/include/cairo
我能看到的唯一区别是路径是绝对的而不是相对的，但如果他找不到库，他会说出来......
I'm trying to link to a static library, libcovis.a. Everything looks fine but I still have
undefined reference to `CoViG_PublicDemo::MoInS::reset()'
I checked that the name exists in the library
$nm libcovis.a | grep reset
...
_ZN16CoViG_PublicDemo5MoInS5resetEv
...
I'm using linking arguments -L/path/to/libcovis.a -lcovis
What am I doing wrong ?
Edit:
The error might be something else, if do
gcc main.cpp -I/usr/include/opencv -I/usr/include/cairo -I../../Source -o slam -rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo ../../Source/libcovis.a ../../Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
It works !
But when I'm in KDevelop using cmake, I doesn't work anymore. I use
CMAKE_EXE_LINKER_FLAGS:STRING=-rdynamic -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXi -lxml2 -lboost_filesystem-mt -llapack -lblas -lcv -lcxcore -lcvaux -lhighgui -lcairo /usr/local/src/CoViS-0.0.0-1/Source/libcovis.a /usr/local/src/CoViS-0.0.0-1/Source/contrib/gnuplot_i/libcovis_contrib_gnuplot_i.a -lgl2ps
CMAKE_CXX_FLAGS:STRING=-I/usr/local/src/CoViS-0.0.0-1/Source -I/usr/include/opencv -I/usr/include/cairo
The only difference I can see is that the paths are absolute and not relative, but if he couldn't find the libs, he would say it...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
那里有两个不同的问题，第一个是最简单的，您使用了错误的编译器选项。 -L 选项告诉链接器在查找库时也在目录中查找。 -l 告诉它链接特定的库。要链接，您可以使用：
或
如果同一库作为动态库存在于同一目录中，则强制静态链接。
第二个潜在问题是链接器命令行中静态库的顺序确实很重要，因此如果存在对不同静态库的依赖性，这也可能是一个问题。
链接器将按命令行中的顺序处理库，并且从每个静态库中，它只会提取所需的符号（具有链接器拥有的尽可能多的信息）当时）。在上面的命令行中，链接器将从
dependent中提取test.o所需的符号，这可能会向程序添加新的未定义符号（依赖项依赖）。当它处理provider时，它将填充这些符号。如果命令行中的顺序相反，则dependent所需的符号（但test.o不需要）将不会添加到可执行文件中，因为链接器不会将其添加到可执行文件中。知道处理provider时将需要这些符号。There are two different issues there, the first of which is the simplest, you have used the wrong compiler options. The -L option tells the linker to also look in the directory when looking for a library. The -l tells it to link the specific library. To link you would then use:
or
To force static linking if the same library is present as a dynamic library in the same directory.
The second potential issue is that the order of static libraries in the linker command line does matter, so that might also be an issue if there is a dependency on different static libs.
The linker will process the libraries in order as they are in the command line, and from each static lib it will only pull those symbols that are required (with as much information as the linker has at that time). In the command line above, the linker will extract from
dependentthe symbols it needs fortest.o, and that might in turn add new undefined symbols to the program (the dependencies ofdependent). When it processesproviderit will fill in those symbols. If the order was reversed in the command line, the symbols that are required bydependentbut not bytest.owould not be added to the executable, as the linker does not know that those symbols will be needed when processingprovider.参数应该像
-L/path/to/ -lcovis吗？此外，目标文件应放在库之前，例如
g++ obj1.o obj2.o -L/path/to/ -lcovis。
Should the arguments be like
-L/path/to/ -lcovis?Besides, object files should be placed before libs, for example
g++ obj1.o obj2.o -L/path/to/ -lcovis.如果您看到链接在一个上下文中成功，但在另一个上下文中失败，我怀疑问题可能是由链接操作的执行顺序引起的，因为链接器将丢弃库中的符号（如果在该点不需要它们）该库被引用。
这是一个解释的链接： http://www.network-theory.co .uk/docs/gccintro/gccintro_18.html
我过去遇到过类似的情况，发现链接顺序是问题的原因。
If you see the link succeeding in one context but not another, I suspect the problem may be caused by the order in which the link operation is executed as the linker will discard symbols in a library if they're not needed at the point in which the library is referenced.
Here is a link explaining: http://www.network-theory.co.uk/docs/gccintro/gccintro_18.html
I've run into similar situations in the past the linking order was found to be the cause of the problem.