使用库中定义的模板时找不到符号

Question

我正在尝试在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)

Answer 1

基本上发生的事情是,如果我说,你只在标题中有定义

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;
}

这将编译但不链接.

输出:

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&);这里"链接器找不到它.

编译和链接

#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();" 它声明函数存在(但编译器再次不知道它在哪里,它内部的代码,只是它存在)我重复了一遍.

让我们来看看证明

命令

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是"void"返回类型.

开头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东西,链接器会找到它自己)

在关闭 USE HEADER GUARDS并使用模板时,在结束标题后面的底部放置#include file.cpp.这样你可以照常包含头文件:)