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混合共享和非共享

回答

相關問題