在测试中无法从项目中链接目标文件 [英] Trouble Linking object files from project in Tests
问题描述
我试图链接一些目标文件，以便可以在Codelite IDE中使用UnitTest ++编写测试.神秘地，教程没有说明如何使用(不同)项目中的.o文件. /p>
如果我使用的是命令行，则该线程向我展示了如何执行此操作.但是，我在Codelite编辑器中遇到了更多困难.在其他线程中接受的答案说"[在codelite的IDE中，这已添加到链接器的选项文本框中，"，但是，我发现情况并非如此.
我将这些路径添加到Library Search Path点中的这些.o文件，然后在此下方的Libraries点中添加各个文件的名称.当我这样做时，出现/usr/bin/ld: cannot find -l<stuff>错误.如果省略Library点中特定文件的名称，则会出现undefined reference to错误.
我是否必须将原始项目编译为库才能解决此问题?还是有我看不到的解决方案?我要运行的my_class_test.cpp文件如下所示:
#include <UnitTest++/UnitTest++.h>
#include "my_class.h"
SUITE(MyClassTest)
{
class MCFixture
{
public:
MyClass me;
MCFixture() : me("a", "b", "c") {};
};
TEST_FIXTURE(MCFixture, ConstructorTest)
{
CHECK_EQUAL(1.0, 1.0);
}
} //SUITE(MyClassTest)
CodeLite假定您在库框中输入的名称是您所使用的值
想要传递给链接器-l选项.
链接器选项-lfoo指示链接器首先在目录中进行搜索
您可以使用-Ldir选项进行指定，然后在其默认搜索目录中，
对于文件libfoo.so(共享库)或libfoo.a(静态
图书馆).找到任何一个时，它都会停止搜索.如果在同一个搜索目录中找到两者或两者，则将首选
libfoo.so.选定的库(如果找到)将输入到链接中.否则
链接器将给出错误:cannot find -lfoo.
因此，如果您指定了链接程序搜索目录-/home/me/other/project/Debug，请说-
然后在库框中输入foo.o，bar.o，然后输入
链接器将搜索文件:
/home/me/other/project/Debug/libfoo.o.{so|a}
/home/me/other/project/Debug/libbar.o.{so|a}
不存在，并且会告诉您:cannot find -l{foo|bar}.o
-l选项的一个变体-l:name，它指示
链接器，其中name是要搜索的文件的精确名称.因此，如果
您从 Libraries 框中删除foo.o，bar.o，然后输入:
-l:foo.o
-l:bar.o
在链接器选项框中，您的链接将成功(除非存在其他错误).
当然，foo.o和bar.o是目标文件，不是库，都是静态的
还是动态的，因此强制链接以在图书馆搜索中找到它们有点
即使正确的做法也会产生纠缠.
似乎您已经编写了一些应用程序项目，现在您想编写 另一个项目，用于对应用程序使用的功能和/或类进行单元测试.
这是一种常见的情况，标准解决方案是三个项目:
- 项目A:构建一个(静态或共享)库，该库实现要测试的组件并导出其组件 API.
- 项目B:构建您的应用程序，
#include-头文件并从项目A链接库. - 项目C:构建单元测试运行程序，并
#include-头文件并从项目A链接库.
使项目B和C取决于项目A.在CodeLite中，您可以使用 Build Order 项目设置来执行此操作.
从长远来看，您将发现此解决方案比保持解决方案更可维护 最新的单元测试运行程序的链接选项，以及由您的应用程序生成的任何目标文件.
I am trying to link some of the object files so that I can write tests using UnitTest++ in the Codelite IDE. Mysteriously, the tutorial does not say how to use .o files from a (different) project.
If I was using the command line, this thread shows me how to do that. However, I am having more difficulty in the Codelite editor. The accepted answer in this other thread says "[i]n the codelite's IDE, this is added in the linker's option textbox," however, I am not finding that to be the case.
I add the path to these .o files in the Library Search Path spot, and then I add the name of the individual files in the Libraries spot just below this. When I do this I get the /usr/bin/ld: cannot find -l<stuff> error. If I omit the names of the specific files in the Library spot, I get the undefined reference to error.
Do I have to compile the original project as a library to get around this? Or is there a solution I don't see? The my_class_test.cpp file that I want to run looks something like this:
#include <UnitTest++/UnitTest++.h>
#include "my_class.h"
SUITE(MyClassTest)
{
class MCFixture
{
public:
MyClass me;
MCFixture() : me("a", "b", "c") {};
};
TEST_FIXTURE(MCFixture, ConstructorTest)
{
CHECK_EQUAL(1.0, 1.0);
}
} //SUITE(MyClassTest)
CodeLite assumes that the names you write in Libraries box are values you
want to pass to the linker -l option.
The linker option -lfoo directs the linker to search, first in the directories
you specify with the -Ldir option, then in its default search directories,
for either of the files libfoo.so (a shared library) or libfoo.a (a static
library). It stops searching when it finds either one. If it finds both or them in the same search directory it will prefer
libfoo.so. The selected library, if found, will be input to the linkage. Otherwise
the linker will given an error: cannot find -lfoo.
So, if you've specified a linker search directory - /home/me/other/project/Debug, say -
and in the Libraries box you've entered maybe foo.o, bar.o, then the
linker is going to search for files:
/home/me/other/project/Debug/libfoo.o.{so|a}
/home/me/other/project/Debug/libbar.o.{so|a}
which don't exist, and is going to tell you: cannot find -l{foo|bar}.o
There is a variation of the -l option, -l:name, which instructs the
linker that name is the exact name of the file to search for. So, if
you remove foo.o, bar.o from the Libraries box, and enter:
-l:foo.o
-l:bar.o
in the Linker options box, your linkage will succeed (barring other errors).
Of course, foo.o and bar.o are object files, not libraries, either static
or dynamic, so coercing the linkage to find them in library search is a bit of
a kludge even when you do it right.
It seems that you've written some application project and now you want to write another project to unit-test functions and/or classes employed by the application.
This is a commonplace situation to which the standard solution is three projects:
- Project A: Builds a (static or shared) library that implements the components to be tested and exports their APIs.
- Project B: Builds your application,
#include-ing the header file(s) and linking the library from Project A. - Project C: Builds the unit-test runner, also
#include-ing the header file(s) and linking the library from Project A.
Make Projects B and C depend on project A. In CodeLite you can do this with the Build Order project settings.
You'll find this solution more maintainable in the long run than keeping the unit-test runner's linkage options up-to-date with whatever object files are generated by your application.
这篇关于在测试中无法从项目中链接目标文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
