type_to_string not found in 'core' and more using clang-19 on MacOS Sequoia

[demfabris]

1. Operating system: MacOS Sequoia
2. The way you installed OpenCV: brew install opencv
3. OpenCV version: $opencv_version: 4.10.0
4. rustc version (rustc --version): 1.81

Clean library crate with a single import Using opencv-rs 0.93

use opencv::core::Mat;

env variables set:

export LIBCLANG_PATH=$(brew --prefix llvm)/lib
export DYLD_LIBRARY_PATH=$(brew --prefix llvm)/lib
export DYLD_FALLBACK_LIBRARY_PATH="$(xcode-select --print-path)/Toolchains/XcodeDefault.xctoolchain/usr/lib/"
export LIBRARY_PATH=/usr/local/lib:/usr/lib:/opt/homebrew/lib
export LDFLAGS=-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/local/lib  

6. Attach the full output of the following command from your project directory:

stacktrace.txt

[YangKa]

I also encountered this problem. Have you solved it? @demfabris

[peterjoel]

I'm also experiencing the same problem.

These method calls are all feature-gated, but the feature ocvrs_opencv_branch_32 feature does not exist.

e.g. in /opencv-0.93.1/src/manual/core/mat.rs:3:

#[inline]
fn match_format<T: DataType>(mat_type: i32) -> Result<()> {
	let out_type = T::opencv_type();
	if mat_type == out_type {
		Ok(())
	} else {
		#[cfg(not(ocvrs_opencv_branch_32))]
		let mat_type = core::type_to_string(mat_type)?;
		#[cfg(not(ocvrs_opencv_branch_32))]
		let out_type = core::type_to_string(out_type)?;
		Err(Error::new(
			core::StsUnmatchedFormats,
			format!("Mat type is: {mat_type}, but requested type is: {out_type}"),
		))
	}
}

[demfabris]

TL;DR

Use DOCS_RS=1 cargo build for now.

Some context

I'm pretty sure it has to do with the unconventional way the source code is compiled. Module core is defined in /docs/core.rs and the build step moves these files to OUT_DIR for compilation.

I managed to successfully build with DOCS_RS=1 cargo build. This indicates that the copying logic is not working properly here: build/docs.rs

I'm lacking too much context to attempt a fix here so I'll wait for owners input

[twistedfall]

From the looks of it seems like the binding to the core OpenCV module are not being generated correctly. If possible, can anyone experiencing this error run a cargo build -vv, note down the value of === Placing generated bindings into: <BINDING_DIR> and then share the contents of the <BINDING_DIR>/core.rs file?

[twistedfall]

Another potential culprit is the clang-19, I have only tested up to clang-18 so if possible can anyone can confirm that downgrading to clang-18 fixes the issue?

[demfabris]

From the looks of it seems like the binding to the core OpenCV module are not being generated correctly. If possible, can anyone experiencing this error run a cargo build -vv, note down the value of === Placing generated bindings into: <BINDING_DIR> and then share the contents of the <BINDING_DIR>/core.rs file?

From the stack trace file I attached: <crateRoot>/target/debug/build/opencv-31aa7a5943655f3d/out/opencv

[twistedfall]

@demfabris Can you please attach that whole file so I can inspect it?

[YangKa]

Another potential culprit is the clang-19, I have only tested up to clang-18 so if possible can anyone can confirm that downgrading to clang-18 fixes the issue?

clang-18 is ok

[twistedfall]

@YangKa Thanks for checking, I'll investigate

[chexov]

From the looks of it seems like the binding to the core OpenCV module are not being generated correctly. If possible, can anyone experiencing this error run a cargo build -vv, note down the value of === Placing generated bindings into: <BINDING_DIR> and then share the contents of the <BINDING_DIR>/core.rs file?

Attached is an output of the target/debug/build/opencv-ecad4525e83befdf/out/opencv/core.rs after running cargo build -vv on a clean build core.rs.txt

clang --version
Homebrew clang version 19.1.1
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/llvm/19.1.1/bin

[twistedfall]

@demfabris @YangKa @peterjoel @chexov Can you please try the 0.93.2 version to see if it fixes the issue you're encountering? I wasn't able to reproduce this exact issue on Linux, but I did encounter a similar issue with clang-19 that is now solved in v0.93.2 so I hope it will fix it for you too.

[twistedfall]

I'm assuming that the problem is now fixed and will close this issue, but please feel free to reopen if it still persists.