opencv V3混合共享和非共享

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

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专家，但不能成为一个错过引导构建过程的问题吗？

来源

2015-12-30 Kellerspeicher

那么，Ubuntu的ffmpeg软件包并不是真正的ffmpeg软件包，而是伪造的libavcodec库。这是一个分叉。除此之外，您可以编辑CMakeCache.txt文件并将'/ usr/lib/x86_64-linux-gnu/libavcodec.so'添加到'FFMPEG_LIBRARIES'或一个类似命名的变量。 – usr1234567

我认为OpenCV 3.1比OpenCV 3.0更稳定 – sturkmen

是的，它只是一个没有质量声明的正式命名。但官方稳定性不会低于3.0。我主要使用3.1，没有问题，也没有在3.0中。 – Kellerspeicher

谢谢usr1234567。你把我放在正确的轨道上，问题现在已修复。

这是关于avcodec女巫在Ubuntu中没有错误标签，但由于历史原因在openCV的cmake文件内错误标记。但那不是问题。

问题是cmake寻找图书馆有点奇怪的搜索策略。它似乎更喜欢针对“/ usr/lib”的“/ usr/local/lib”。一般来说，这是可以的。但是，如果在本地没有动态库的情况下存在静态库，它将使用静态而不是在/ usr/lib中搜索动态库。

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

来源

2015-12-31 18:18:37 Kellerspeicher

opencv V3混合共享和非共享

回答

相关问题