我正在尝试在iOS应用程序中使用adobe xmp库,但是我遇到了链接错误。我的路径中有适当的标头和库,但是我收到链接错误。我仔细检查以确保标题和库在我的路径上。我检查了方法的错位名称,但它们不在库中(我使用nm
命令检查)。我做错了什么?
图书馆标题:
#if defined ( TXMP_STRING_TYPE )
#include "TXMPMeta.hpp"
#include "TXMPIterator.hpp"
#include "TXMPUtils.hpp"
typedef class TXMPMeta <TXMP_STRING_TYPE> SXMPMeta; // For client convenience.
typedef class TXMPIterator <TXMP_STRING_TYPE> SXMPIterator;
typedef class TXMPUtils <TXMP_STRING_TYPE> SXMPUtils;
.mm文件:
#include <string>
using namespace std;
#define IOS_ENV
#define TXMP_STRING_TYPE string
#import "XMP.hpp"
void DoStuff()
{
SXMPMeta meta;
string returnValue;
meta.SetProperty ( kXMP_NS_PDF, "test", "{ formId: {guid} }" );
meta.DumpObject(DumpToString, &returnValue);
}
链接错误:
(null): "TXMPMeta<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::DumpObject(int (*)(void*, char const*, unsigned int), void*) const", referenced from:
(null): "TXMPMeta<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::TXMPMeta()", referenced from:
(null): "TXMPMeta<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::SetProperty(char const*, char const*, char const*, unsigned int)", referenced from:
(null): "TXMPMeta<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >::~TXMPMeta()", referenced from:
(null): Linker command failed with exit code 1 (use -v to see invocation)
答案 0 :(得分:8)
基本上发生的事情是你只在标题中有定义 如果我说
template<class T> T something(T);
某处,它告诉编译器“信任我兄弟,它存在,留给链接器”
并将符号添加到目标文件中,就好像它确实存在一样。因为它可以看到原型,它知道有多少堆栈空间,它返回什么类型等等,所以它只是设置它,所以链接器可以出现并将函数的地址放入。
但在你的情况下,没有地址。您/ MUST /必须在同一个文件中定义模板(不仅仅是声明),因此编译器可以创建一个(具有弱连接),所以这里假设它们存在,但是它没有从模板中实际标记出这个类的位置,所以链接器找不到它,因此错误。
现在我会回答我的答案,希望这会有所帮助。
附录1:
template<class T> void output(T&);
int main(int,char**) {
int x = 5;
output(x);
return 0;
}
这将编译但 NOT 链接。
输出:
if ! g++ -Isrc -Wall -Wextra -O3 -std=c++11 -g -gdwarf-2 -Wno-write-strings -MM src/main.cpp >> build/main.o.d ; then rm build/main.o.d ; exit 1 ; fi
g++ -Wall -Wextra -O3 -std=c++11 -g -gdwarf-2 -Wno-write-strings -Isrc -c src/main.cpp -o build/main.o
g++ build/main.o -o a.out
build/main.o: In function `main':
(my home)/src/main.cpp:13: undefined reference to `void output<int>(int&)'
collect2: error: ld returned 1 exit status
make: *** [a.out] Error 1
(我为此劫持了一个开放的项目名称)
正如您所看到的,编译命令工作正常(以-o build / main.o结尾的那个),因为我们告诉它“看看这个函数是否存在”
因此在目标文件中它向链接器说明(以某些“名称管理形式”来保留模板)“将位置放在void输出的内存中(int&amp;);这里”链接器找不到它。
编译和链接
#include <iostream>
template<class T> void output(T&);
int main(int,char**) {
int x = 5;
output(x);
return 0;
}
template<class T> void output(T& what) {
std::cout<<what<<"\n";
std::cout.flush();
}
注意第2行,我们告诉它“存在一个函数,T中的模板称为输出,它不返回任何内容并采用T引用”,这意味着它可以在main函数中使用它(记住它在解析主函数时)函数它还没有看到输出的定义,它刚刚被告知它存在),然后链接器修复它。 “虽然现代编译器更聪明(因为我们有更多内存:))并强奸了代码的结构,链接时间优化更能做到这一点,但这是它以前的工作方式,以及它如何被考虑这几天工作。
输出:
make all
if ! g++ -Isrc -Wall -Wextra -O3 -std=c++11 -g -gdwarf-2 -Wno-write-strings -MM src/main.cpp >> build/main.o.d ; then rm build/main.o.d ; exit 1 ; fi
g++ -Wall -Wextra -O3 -std=c++11 -g -gdwarf-2 -Wno-write-strings -Isrc -c src/main.cpp -o build/main.o
g++ build/main.o -o a.out
正如你所看到的那样编译得很好并且链接得很好。
多个未包含此文件的文件
<强>的main.cpp 强>
#include <iostream>
int TrustMeCompilerIExist();
int main(int,char**) {
std::cout<<TrustMeCompilerIExist();
std::cout.flush();
return 0;
}
<强> proof.cpp 强>
int TrustMeCompilerIExist() {
return 5;
}
编译和链接
make all
if ! g++ -Isrc -Wall -Wextra -O3 -std=c++11 -g -gdwarf-2 -Wno-write-strings -MM src/main.cpp >> build/main.o.d ; then rm build/main.o.d ; exit 1 ; fi
g++ -Wall -Wextra -O3 -std=c++11 -g -gdwarf-2 -Wno-write-strings -Isrc -c src/main.cpp -o build/main.o
if ! g++ -Isrc -Wall -Wextra -O3 -std=c++11 -g -gdwarf-2 -Wno-write-strings -MM src/proof.cpp >> build/proof.o.d ; then rm build/proof.o.d ; exit 1 ; fi
g++ -Wall -Wextra -O3 -std=c++11 -g -gdwarf-2 -Wno-write-strings -Isrc -c src/proof.cpp -o build/proof.o
g++ build/main.o build/proof.o -o a.out
(输出5)
记住#include LITERALLY转储一个文件,其中显示“#include”(+其他一些调整行号的宏),这称为翻译单元。而不是使用头文件来包含“int TrustMeCompilerIExist();”声明该函数存在(但编译器再次不知道它在哪里,它内部的代码,只是它存在)我重复了一遍。
让我们看看proof.o
<强>命令强>
objdump proof.o -t
<强>输出强>
proof.o: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l df *ABS* 0000000000000000 proof.cpp
0000000000000000 l d .text 0000000000000000 .text
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 l d .bss 0000000000000000 .bss
0000000000000000 l d .debug_info 0000000000000000 .debug_info
0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev
0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges
0000000000000000 l d .debug_line 0000000000000000 .debug_line
0000000000000000 l d .debug_str 0000000000000000 .debug_str
0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack
0000000000000000 l d .eh_frame 0000000000000000 .eh_frame
0000000000000000 l d .comment 0000000000000000 .comment
0000000000000000 g F .text 0000000000000006 _Z21TrustMeCompilerIExistv
在那里的底部,有一个函数,在偏移6处进入文件,带有调试信息,(虽然g是全局的)你可以看到它被称为_Z(这就是_为某些东西保留的原因,我忘了究竟是什么......但它与此有关)并且Z是“整数”,21是名称长度,在名称之后,v是“无效”返回类型。
开头btw的零是段号,记住二进制文件可能很大。
<强>拆卸强> 运行:
objdump proof.o -S
给出了
proof.o: file format elf64-x86-64
Disassembly of section .text:
0000000000000000 <_Z21TrustMeCompilerIExistv>:
int TrustMeCompilerIExist() {
return 5;
}
0: b8 05 00 00 00 mov $0x5,%eax
5: c3 retq
因为我有-g你可以看到它把程序集所涉及的代码放在一起(对于更大的函数更有意义,它会向你显示以下指令,直到下一个代码块实际执行)通常不会那里。
<强> main.o 强>
这是符号表,以与上面相同的方式获得:
objdump main.o -t
main.o: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l df *ABS* 0000000000000000 main.cpp
0000000000000000 l d .text 0000000000000000 .text
0000000000000000 l d .data 0000000000000000 .data
0000000000000000 l d .bss 0000000000000000 .bss
0000000000000000 l d .text.startup 0000000000000000 .text.startup
0000000000000030 l F .text.startup 0000000000000026 _GLOBAL__sub_I_main
0000000000000000 l O .bss 0000000000000001 _ZStL8__ioinit
0000000000000000 l d .init_array 0000000000000000 .init_array
0000000000000000 l d .debug_info 0000000000000000 .debug_info
0000000000000000 l d .debug_abbrev 0000000000000000 .debug_abbrev
0000000000000000 l d .debug_loc 0000000000000000 .debug_loc
0000000000000000 l d .debug_aranges 0000000000000000 .debug_aranges
0000000000000000 l d .debug_ranges 0000000000000000 .debug_ranges
0000000000000000 l d .debug_line 0000000000000000 .debug_line
0000000000000000 l d .debug_str 0000000000000000 .debug_str
0000000000000000 l d .note.GNU-stack 0000000000000000 .note.GNU-stack
0000000000000000 l d .eh_frame 0000000000000000 .eh_frame
0000000000000000 l d .comment 0000000000000000 .comment
0000000000000000 g F .text.startup 0000000000000026 main
0000000000000000 *UND* 0000000000000000 _Z21TrustMeCompilerIExistv
0000000000000000 *UND* 0000000000000000 _ZSt4cout
0000000000000000 *UND* 0000000000000000 _ZNSolsEi
0000000000000000 *UND* 0000000000000000 _ZNSo5flushEv
0000000000000000 *UND* 0000000000000000 _ZNSt8ios_base4InitC1Ev
0000000000000000 *UND* 0000000000000000 .hidden __dso_handle
0000000000000000 *UND* 0000000000000000 _ZNSt8ios_base4InitD1Ev
0000000000000000 *UND* 0000000000000000 __cxa_atexit
看看它是如何说未定义的,那是因为它不知道它在哪里,它只知道它存在(连同标准的lib东西,链接器会找到它自己)
结束 使用HEADER GUARDS并使用模板将#include file.cpp放在封底标题后面的底部。这样你可以像往常一样包含头文件:)
答案 1 :(得分:2)
XMP SDK Toolkit 附带的示例中提供了您的问题的答案。客户端必须编译XMP.incl_cpp以确保生成所有客户端粘合代码。通过将其包含在您的一个源文件中来完成此操作。
为了您的准备参考,我将粘贴在模板类和访问 XMP SDK Toolkit 附带的XMPProgrammersGuide.pdf的部分中的更详细说明下面p>
模板类和访问API
完整的客户端API在TXMP * .hpp头文件中定义并记录。 TXMP *类是C ++模板类,必须使用字符串类(如std :: string)进行实例化,该字符串类用于返回属性值,序列化XMP等文本字符串。要允许您的代码访问整个XMP API,您必须:
提供一个字符串类,例如std :: string来实例化模板类。
通过包含必要的定义和标头来提供对XMPCore和XMPFiles的访问。为此,请在源代码中添加必要的define和includes指令,以便将所有必需的代码合并到构建中:
#include <string>
#define XMP_INCLUDE_XMPFILES 1 //if using XMPFiles
#define TXMP_STRING_TYPE std::string
#include "XMP.hpp"
SDK提供了模板类的完整参考文档,但必须实例化模板才能使用。您可以阅读头文件(TXMPMeta.hpp等)以获取信息,但不要将它们直接包含在您的代码中。有一个整体头文件XMP.hpp,它是C ++客户端应该使用#include指令唯一包含的头文件。阅读此文件中的说明以实例化模板类。完成此操作后,API可通过名为SXMP *的具体类获得;即SXMPMeta,SXMPUtils,SXMPIterator和SXMPFiles。本文档引用了SXMP *类,您可以实例化它们并提供静态函数。
客户端必须编译XMP.incl_cpp以确保生成所有客户端粘合代码。通过将其包含在您的一个源文件中来完成此操作。 有关命名空间URI和选项标志的类型和常量的详细信息,请阅读XMP_Const.h。