Build failed on when using diesel crate

[jerry73204]

The issue arises when I'm by crate with opencv-rust with feature opencv-4. Here is my scenario.

item	desc
OS	Ubuntu 18.04
OpenCV 4 directory	/opt/opencv4.2.0
opencv-rust features	opencv-4,buildtime-bindgen,contrib
env vars	PKG_CONFIG_PATH=/opt/opencv4.2.0/lib/pkgconfig, LD_LIBRARY_PATH=/opt/opencv4.2.0/lib

By calling cargo build [--release], the opencv(build) and opencv pass without errors. When finally reaching to my binary, it failed with the following error.

error: linking with `cc` failed: exit code: 1
  |
  = note: ... # a very long "cc" command
  = note: /usr/bin/ld: warning: libopencv_imgproc.so.4.2, needed by /opt/opencv4.2.0/lib/libopencv_stitching.so, may conflict with libopencv_imgproc.so.3.4
          /usr/bin/ld: /mnt/ssd1/aeon/repos/wayside-portal/web/target/release/deps/libopencv-b240c6adf66d7300.rlib(imgproc.o): undefined reference to symbol '_ZN2cv12findContoursERKNS_11_InputArrayERKNS_12_OutputArrayEiiNS_6Point_IiEE'
          /opt/opencv4.2.0/lib/libopencv_imgproc.so.4.2: error adding symbols: DSO missing from command line
          collect2: error: ld returned 1 exit status

The message includes a long command here.

I see the cause of the problem. The compiler accidentally links to the /usr/lib/x86_64-linux-gnu/libopencv_imgproc.so from Ubuntu repository rather than the desired /opt/opencv4.2.0/lib/libopencv_imgproc.so. It's absolutely the issue of linking order.

I investigate into the erroneous command here. The order turns out to be -L /usr/lib/x86_64-linux-gnu ... -L /opt/opencv4.2.0/lib ... -lopencv_imgproc, so it's expected that the linker picked the one from /usr/lib/x86_64-linux-gnu first. I instructed the cc command with more verbose linker log here, and I confirmed my guess.

Unfortunately, I see no way to manipulate the linking order. Though removing the shipped libopencv-* APT packages on Ubuntu solves the issue, it breaks many other things on a public machine.

[twistedfall]

Hi, can you please post the opencv4.pc file contents from the /opt/opencv4.2.0/lib/pkgconfig directory?

[twistedfall]

And also please the output of cargo build -vv --features opencv-4,buildtime-bindgen,contrib

[jerry73204]

• opencv4.pc
• cargo build -vv

[twistedfall]

Can you please also check if you experience the same problem with both opencv installations present with a new project with just "opencv" dependency? It might be that this library search path is being injected by another crate.

[jerry73204]

Interestingly, I have 4 of them linking opencv with same feature set. Only one of them failed.

EDIT: I think it's not problem of opencv-rust. It's a hard linking order problem that already arises on many build systems. You mess up with -L and rpath. I suppose cargo order the args to native -L -> -L from build.rs. If there are two .so happend to have the same name, you have good luck to pick the desired shared library.

I think a workaround is to use more specific -lopencv_imgproc.4.2.0. It somewhat avoid the problem. However, it cannot tackle with multiple 4.2.0 installations.

[twistedfall]

Will you be able to track down which dependency adds /usr/lib/x86_64-linux-gnu? My bet would be "diesel" because it's the first crate I can see in the build log which has this linking path in its build arguments.

[jerry73204]

Turned out you are right. More specifically, it's pq-sys prints the search path. I found it by grepping across target/*/output. Since the root of the problem is not here, we can consider close this issue.

EDIT: typo

[twistedfall]

Well, yes and no, it’s still a problem with coexisting with other crates so I’d like to investigate if it’s possible to fix it.

[jerry73204]

I discovered another conflicting issue with tesseract crate. It complains about linking to libclang. It happens specifically with buildtime-bindgen feature. I assume they link to different version of libclang.

Here is the error message.

thread '<unnamed>' panicked at 'a `libclang` shared library is not loaded on this thread', /home/aeon/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-0.28.1/src/lib.rs:1618:1

The env

• Ubuntu 18.04 with libclang-6.0-dev and clang-6.0 installed.

Here is the minimal Cargo.toml.

[package]
name = "example"
version = "0.1.0"
authors = ["jerry73204 <[email protected]>"]
edition = "2018"

[dependencies]
opencv = { version = "^0.36.0", default-features = false, features = ["opencv-4", "contrib", "buildtime-bindgen"] }
tesseract = "^0.3.1"

[twistedfall]

Please use version 0.37.0 and enable clang-runtime feature. This issue has just been fixed.

[not-matthias]

I've encountered the same error (thread 'main' panicked at 'a libclang shared library is not loaded on this thread') on Windows using bindgen 0.55 and opencv 0.45.

Adding the clang-runtime feature worked for me too.

[twistedfall]

I'm going to close this issue as it is quite old. If you still experiencing this issue please feel free to reopen.