我有一个Go库,它为C ++
OpenImageIO库(OpenImageiGO)提供绑定。我一直在通过与libOpenImageIO的标准动态链接来构建绑定,但现在尝试静态链接。我遇到了一个问题,无论我尝试使用哪种标志组合,外部链接器都会失败,并出现大量“未定义的引用”错误。我似乎回想起过去曾提到过的这个问题,他说链接器看到符号的顺序存在问题。但我似乎再也找不到此信息。
这是我最近一次构建尝试的简短示例,试图将其链接到boost,OpenColorIO和OpenImageIO的静态构建:
$ export CGO_CPPFLAGS="\
-I/path/to/boost/include \
-I/path/to/OpenColorIO/include \
-I/path/to/OpenImageIO/include"
$ export CGO_LDFLAGS="\
-L/path/to/boost/lib -lboost_thread_static -lboost_system_static \
-L/path/to/OpenColorIO/lib -lopencolorio \
-L/path/to/OpenImageIO/lib -lOpenImageIO"
$ go build -v -x --ldflags '-extldflags "-static"' github.com/justinfx/openimageigo
...
CGO_LDFLAGS="/path/to/boost/lib/libboost_system_static.a" "/path/to/boost/lib/libboost_thread_static.a" "/path/to/OpenColorIO/lib/libopencolorio.a" "/path/to/OpenImageIO/lib/libOpenImageIO.a" "-lstdc++" /vol/apps/go/1.3.0/pkg/tool/linux_amd64/cgo -objdir $WORK/github.com/justinfx/openimageigo/_obj/ -- -I/path/to/boost/include -I/path/to/OpenColorIO/include -I/path/to/OpenImageIO/include -I./cpp -I $WORK/github.com/justinfx/openimageigo/_obj/ -I/path/to/boost/include -I/path/to/OpenColorIO/include -I/path/to/OpenImageIO/include color.go imagebuf.go imagebufalgo.go imagecache.go imageinput.go imageoutput.go imagespec.go oiio.go roi.go
...
/usr/bin/g++ -I . -fPIC -m64 -pthread -fmessage-length=0 -I/path/to/boost/include -I/path/to/OpenColorIO/include -I/path/to/OpenImageIO/include -I./cpp -I $WORK/github.com/justinfx/openimageigo/_obj/ -g -O2 -o $WORK/github.com/justinfx/openimageigo/_obj/all.cpp.o -c ./all.cpp
/usr/bin/g++ -I . -fPIC -m64 -pthread -fmessage-length=0 -o $WORK/github.com/justinfx/openimageigo/_obj/_cgo_.o $WORK/github.com/justinfx/openimageigo/_obj/_cgo_main.o $WORK/github.com/justinfx/openimageigo/_obj/_cgo_export.o $WORK/github.com/justinfx/openimageigo/_obj/color.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/imagebuf.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/imagebufalgo.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/imagecache.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/imageinput.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/imageoutput.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/imagespec.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/oiio.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/roi.cgo2.o $WORK/github.com/justinfx/openimageigo/_obj/all.cpp.o /path/to/boost/lib/libboost_system_static.a /path/to/boost/lib/libboost_thread_static.a /path/to/OpenColorIO/lib/libopencolorio.a /path/to/OpenImageIO/lib/libOpenImageIO.a -lstdc++
这是一些挑剔的错误,因为它的输出非常长:
/path/to/OpenImageIO/lib/libOpenImageIO.a(OpenImageIO_dist^src^libOpenImageIO^color_ocio.cpp.o): In function `ColorConfig':
/path/to/OpenImageIO/OpenImageIO_dist/src/libOpenImageIO/color_ocio.cpp:141: undefined reference to `OpenColorIO::v1::SetLoggingLevel(OpenColorIO::v1::LoggingLevel)'
...
/path/to/OpenImageIO/lib/libOpenImageIO.a(OpenImageIO_dist^src^libOpenImageIO^imagebufalgo_copy.cpp.o): In function `boost::shared_mutex::lock()':
/path/to/boost/include/boost/thread/pthread/shared_mutex.hpp:138: undefined reference to `boost::this_thread::disable_interruption::~disable_interruption()'
OpenImageIO似乎找不到OpenColorIO的引用。而且,OpenImageIO似乎找不到增强的参考。看起来在链接过程中发生的事情的顺序没有使OpenColorIO或boost符号可用于OpenImageIO,因此出现了很多符号错误。
我希望我正在做一些简单而愚蠢的事情,可以在构建过程中纠正它。但是,与默认的动态链接方法相比,使用外部库的cgo静态链接看起来确实更复杂。
@ james-henstridge给出的答案是正确的,除了最后一个打ic之外,我几乎完全熟练。我收到了yaml- cpp
所需的对的引用失败OpenColorIO
,即使看起来顺序正确也是如此。
这是我最新的环境,在这里我处理了必须添加的所有显式静态库:
$ export CGO_CPPFLAGS="-I/usr/local/include -I/usr/include"
$ export CGO_LDFLAGS="\
-L/usr/local/lib \
-L/usr/lib \
-L/usr/lib/x86_64-linux-gnu \
-lOpenImageIO \
-lHalf -lIex -lfreetype -lIlmThread -lImath -lIlmImf -lIlmThread \
-lOpenColorIO \
-lyaml-cpp -ltinyxml \
-lboost_regex -lboost_filesystem -lboost_thread -lboost_system \
-ltiff -lgif -lpng -ljpeg -lz \
-lrt -ldl"
$ go test -v -x --ldflags '-extldflags "-static"' github.com/justinfx/openimageigo
...
/home/justin/src/OpenColorIO/src/core/OCIOYaml.cpp:329: undefined reference to `YAML::Node::begin() const'
...
/home/justin/src/OpenColorIO/build/ext/dist/include/yaml-cpp/nodereadimpl.h:79: undefined reference to `YAML::Node::GetScalar(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) const'
...
/usr/local/lib/libOpenColorIO.a(OCIOYaml.cpp.o): In function `_FindFromNodeAtIndex':
/home/justin/src/OpenColorIO/build/ext/dist/include/yaml-cpp/nodeutil.h:53: undefined reference to `YAML::Node::FindAtIndex(unsigned long) const'
collect2: ld returned 1 exit status
没关系更新#1。它与特定问题有关,OpenColorIO
而不是一般问题。
-l
与静态库链接时,标志的顺序很重要。如果使用链接-lfoo -lbar -lbaz
,libbar.a
则只会在libbar.a
和中搜索所需的任何符号libbaz.a
。即使libfoo.a
包含您需要的符号,链接器也不会找到它们。
发生的情况是,对于每个库,链接器都会解压缩存档文件,并添加包含目标符号的目标文件,这些符号由之前的内容引用。如果不需要存档中的特定对象文件,则将其忽略。
解决方法是确保在链接器标志所依赖的库之前,先列出每个库。如果有任何依赖关系循环(不应存在),则可能有必要列出一个库两次。
问题内容: 因此,该小组中有很多建议您可以随时进行的工作(尽管不在cgo文档中): 但是,它似乎不起作用: 使用动态库,并检查生成的文件,这似乎可以很好地工作,它实际上在其中带有符号“ x”: 但显然只是bridge.cgo2.o中的标记: 我究竟做错了什么? 对于ref,c标头: 和代码: -- 编辑: 不,-L和-l也不起作用;实际上,在Google网上论坛上有一些具体讨论,认为该(-l /
主要内容:静态链接库,动态链接库,总结我们知道,C、C++程序从源文件到生成可执行文件需经历 4 个阶段,分别为预处理、编译、汇编和链接,本节将重点围绕链接阶段,对静态链接库和动态链接库做详细的讲解。 有关链接操作的具体细节,感兴趣的读者可阅读《 到底什么是链接,它起到了什么作用?》和《 符号——链接的粘合剂》这两节。总的来说链接阶段要完成的工作,就是将同一项目中各源文件生成的目标文件以及程序中用到的库文件整合为一个可执行文件。 通过
使用clang链接AFN .a静态库 AFN静态库的生成不是重点, 以链接使用为主 一、准备 在staticLib文件夹下新建test.m文件, 代码如下 #import <Foundation/Foundation.h> #import <AFNetworking.h> int main() { AFHTTPSessionManager *manager = [AFHTTPSe
问题内容: 是否可以使用静态类将静态方法链接在一起?说我想做这样的事情: 。。。并且显然我希望将$ value分配给数字14。这可能吗? 更新 :它不起作用(您不能返回“自我”-它不是实例!),但这就是我的想法带给我的地方: 解决了这些问题之后,我认为仅使用类实例而不是尝试链接静态函数调用(这似乎不太可能,除非可以对上述示例进行一些调整)才有意义。 问题答案: 我喜欢上面Camilo提供的解决方案
问题内容: 在Linux上的“ C”上, 我需要静态库来静态链接,还是需要足够的共享库?如果没有,为什么不呢?(它们不包含相同的数据吗?) 问题答案: 是的,您需要静态库来构建静态链接的可执行文件。 静态库是编译对象的捆绑包。静态链接到库时,实际上与获取该库的编译结果,将它们解压缩到当前项目中以及将它们当作自己的对象使用一样。 动态库已链接。这意味着一些信息,例如重定位,已经被修复并丢弃。 此外,
问题内容: Java 8之前的Java版本要求本机代码必须位于共享库中,但是我已经读到Java 8可以在JNI中使用静态链接库。我已经搜索了示例,但找不到任何示例。 如何将JNI库静态链接到Java应用程序? 问题答案: Java SE 8规范已更改为支持静态链接,并且静态链接在JDK中实现。在System.loadLibrary的规范中对此进行了简要介绍。它所引用的JNI规范的各个部分在此处和此