Ask Your Question
0

Undefined ld references when building from source

asked 2019-07-29 16:29:42 -0500

updated 2019-07-29 16:47:38 -0500

berak gravatar image

I'm getting various undefined references to atomic types.

[ 40%] Linking CXX executable ../../bin/opencv_perf_core
/usr/bin/ld: ../../lib/libopencv_core.so.4.1.1: undefined reference to `__atomic_fetch_add_8'
/usr/bin/ld: ../../lib/libopencv_core.so.4.1.1: undefined reference to `__atomic_fetch_sub_8'
/usr/bin/ld: ../../lib/libopencv_core.so.4.1.1: undefined reference to `__atomic_store_8'
/usr/bin/ld: ../../lib/libopencv_core.so.4.1.1: undefined reference to `__atomic_load_8'
/usr/bin/ld: ../../lib/libopencv_core.so.4.1.1: undefined reference to `__atomic_compare_exchange_8'

I'm trying to build OpenCV-4.1.1 from source on a Raspberry Pi 3. Currently using these options in CMake. Any ideas?

cmake -D CMAKE_BUILD_TYPE=RELEASE \
   -D CMAKE_INSTALL_PREFIX=/usr/local/ \
   -D OPENCV_EXTRA_MODULES_PATH=~/opencv_contrib-master/modules/ \
   -D ENABLE_NEON=ON \
   -D ENABLE_VFPV3=ON \
   -D ENABLE_LTO=ON \
   -D CPU_BASELINE=NEON \
   -D WITH_TBB=ON \
   -D WITH_OPENCL=ON \
   -D WITH_GSTREAMER=ON \
   -D BUILD_EXAMPLES=OFF \
   -D BUILD_TESTS=OFF \
   -D BUILD_SHARED=OFF ..
edit retag flag offensive close merge delete

Comments

can you take a look here ? seems you're not alone with it.

berak gravatar imageberak ( 2019-07-30 16:05:05 -0500 )edit
1

Lol, that's just me under a different name. I posted there as this question itself wasn't getting a whole lot of traction.

EmDash00 gravatar imageEmDash00 ( 2019-07-30 16:08:37 -0500 )edit

yea, but if adding -latomic to the libs helped, this should be going somewhere, no ?

(also, pi users are a rare niche here, especially ppl who could help)

berak gravatar imageberak ( 2019-07-30 16:17:48 -0500 )edit
1

Oh totally, especially with all the optimizations I'm running on this thing.

I was hoping to fully optimize OpenCV to milk every last thing I could get from the pi's processor for work. One build actually worked with those settings minus -D ENABLE_LTO=ON on 4.1.0; however, I had gotten the archive rather than cloned it from git so I couldn't build any debian packages with proper versioning to save me the trouble of trying to compile it again.

Though later in the build I got another linker error: undefined reference to Imf_opencv

Though this time I'm not sure what to link to resolve it. Looking towards this https://codeyarns.com/2013/10/04/how-... maybe? I do have IPP on the pi as well (I had no idea that was even an optimization til now).

EmDash00 gravatar imageEmDash00 ( 2019-07-30 16:24:32 -0500 )edit

undefined reference to Imf_opencv

oh, that's retated to the OPENEXR support for imread(). you'll only strictly NEED this if you plan to venture into HDR (floating point) image processing. if that's not on your map, you might be safe to simply disable support for that with cmake -DWITH_OPENEXR=OFF -DBUILD_OPENEXR=OFF

berak gravatar imageberak ( 2019-07-30 16:41:50 -0500 )edit

Now i'm getting undefined references to google::protobuf when linking... What the heck is going on? Why is nothing linking properly?

EmDash00 gravatar imageEmDash00 ( 2019-08-01 10:25:01 -0500 )edit

1 answer

Sort by ยป oldest newest most voted
0

answered 2019-08-03 18:36:23 -0500

Ok so I eventually figured it out myself. The -latomic fix has a more elegant solution, namely with -DOPENCV_EXTRA_EXE_LINKER_FLAGS=-latomic.

Next some libraries seem to not be mapping correctly. Whatever may be the cause of that, this option fixed it: -DENABLE_PRECOMPILED_HEADERS=OFF.

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2019-07-29 16:28:37 -0500

Seen: 1,503 times

Last updated: Aug 03 '19