Question

如果在Ubuntu 14.04.3 LTS上编译，openCV的当前稳定版（V3.0.0）和不稳定版（V3.1.0）混合共享库和非共享库。

Linking CXX shared library ../../lib/libopencv_videoio.so
/usr/bin/ld: /usr/local/lib/libavcodec.a(avpacket.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libavcodec.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [lib/libopencv_videoio.so.3.1.0] Error 1
make[1]: *** [modules/videoio/CMakeFiles/opencv_videoio.dir/all] Error 2
make: *** [all] Error 2

尝试使用libopencv_videoio.so创建libavcodec.a似乎是个问题。有一个bug report，但它只提供建议来检查是否安装了libavcodec.so（这是）以及使用-DBUILD_SHARED_LIBS=OFF来防止创建共享库的解决方法。有谁知道这个问题的原因。 openCV人员只是声明Ubuntu打包的ffmpeg库是不正确的。有什么想法吗？

这个问题似乎很老了。我刚发现一个非常similar question没有回答，但评论了用./configure --enable-shared编译ffmpeg的建议。但是已经有一个共享库/usr/lib/x86_64-linux-gnu/libavcodec.so，显然没有找到。我不是cmake专家，但这不是导致错过的构建过程的问题吗？

Answer 1

谢谢usr1234567 。你让我走上了正确的轨道，现在问题已修复。

所有关于avcodec女巫都没有在Ubuntu中进行虚假标记，但由于历史原因，在openCV的cmake文件中进行了虚假标记。但那不是问题所在。

问题是cmake寻找库有点奇怪的搜索策略。它似乎更喜欢“/ usr / local / lib”对“/ usr / lib”。一般来说这没关系。但是如果本地没有动态lib的静态库，则使用静态而不是在/ usr / lib中搜索动态库。

所以吸取的教训是;使用checkinstall正确清理当地的旧尝试;对cmake的搜索策略不信任：不要指望umake找到唯一的动态库，如果有非分布式静态库，即使唯一的动态库在正确的目录中。

opencv V3混合共享和非共享

1 个答案: