在cgo库中链接第三方静态库 [英] linking 3rd party static libs in cgo library
问题描述
我有一个Go库，它为C ++ OpenImageIO 库提供绑定(
I have a Go library that provides bindings for the C++ OpenImageIO library (OpenImageiGO). I've been happily building my bindings via the standard dynamic linking to libOpenImageIO, but am now trying to link statically. I'm running into an issue where no matter which combination of flags I try, the external linker fails with a ton of "undefined reference" errors. I seem to recall seeing this issue raised in the past, saying that there was an issue regarding the order in which the linker saw the symbols. But I can't seem to find this information again.
这是我最近一次构建尝试的简短示例，试图将其链接到boost，OpenColorIO和OpenImageIO的静态构建:
Here is a brief example of my most recent build attempt, trying to get it to link against static builds of boost, OpenColorIO, and 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++
这是一些挑剔的错误，因为这是非常长的输出:
And here are some of the cherry-picked errors, since it was a very long bit of output:
/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，所以我遇到了很多符号错误.
OpenImageIO can't seem to find references for OpenColorIO. And, OpenImageIO can't seem to find references for boost. It appears like the order in which things are happening during the linking isn't making the OpenColorIO or boost symbols available to OpenImageIO, so I get a bunch of symbol errors.
我希望我所做的事情简单而愚蠢，可以在构建过程中进行纠正.但是，与默认的动态链接方法相比，使用外部库的cgo静态链接看起来确实更复杂.
I'm hoping I am doing something simple and stupid that can be corrected in my build process. But the cgo static linking with external libs does seem a touch more complicated than the default dynamic linking approach.
@ james-henstridge给出的答案是正确的，除了最后一个打h之外，我几乎完全健壮.我收到的 yaml-cpp 引用失败，尽管看起来我的顺序正确，但 OpenColorIO 仍然需要.
The answer given by @james-henstridge was right on, and I am almost fully built, except for one last hiccup. I'm getting failing references for yaml-cpp, needed by OpenColorIO, even though it seems I have the correct order.
这是我最新的环境，在那里我处理了所有必须添加的显式静态库:
Here is my latest env, where I have worked through all of the explicit static libs that had to be added:
$ 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
更新#2
不要担心更新#1.它与 OpenColorIO 特别相关，而不是普遍问题.
Update #2
Nevermind about update #1. It was specifically related to OpenColorIO and not a general issue.
推荐答案
与静态库链接时， -l </code>标志的顺序很重要.如果使用 -lfoo -lbar -lbaz 进行链接，则仅在 libbar.a 和 libbaz.a .即使 libfoo.a 包含您想要的符号，链接器也不会找到它们.
The order of the -l flags matters when you are linking with static libraries. If you link using -lfoo -lbar -lbaz, any symbols required by libbar.a will only be searched for in libbar.a and libbaz.a. Even if libfoo.a contains the symbols you're after, the linker won't find them.
正在发生的事情是，对于每个库，链接器都会解压缩归档文件，并添加包含以前所引用符号的对象文件.如果不需要存档中的特定目标文件，则将其忽略.
What is happening is that for each library, the linker unpacks the archive and adds the object files that contain symbols referenced by whatever came before. If a particular object file in the archive isn't needed, it is ignored.
解决方法是确保在链接器标志所依赖的库之前，先列出每个库.如果存在任何依赖关系循环(不应存在)，则可能有必要列出一个库两次.
The fix is to make sure every library is listed before any it depends on in the linker flags. If there are any dependency loops (which there shouldn't be), it may be necessary to list a library twice.
这篇关于在cgo库中链接第三方静态库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
