Using the Rust bindings (0.1.2-alpha.2) on macOS (13.4.1) arm64
When used in conjunction with rust-bert crate, raises the following error when sqlite-vss is initialised first;
OMP: Error #15: Initializing libomp.dylib, but found libomp.dylib already initialized.
OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/
zsh: abort
Running with KMP_DUPLICATE_LIB_OK=TRUE will cause a segfault instead. If rust-bert is initialised first, no warning will be displayed and just the segfault is raised. A workaround is possible via, OMP_NUM_THREADS=1, where both libraries will now work properly.
This may be just limited to macOS weirdness, I have not yet tried on linux yet.
Understandably, this is a unique use case atop of already experimental bindings, so this is more of a heads up.
Using the Rust bindings (0.1.2-alpha.2) on macOS (13.4.1) arm64
When used in conjunction with rust-bert crate, raises the following error when sqlite-vss is initialised first;
Running with KMP_DUPLICATE_LIB_OK=TRUE will cause a segfault instead. If rust-bert is initialised first, no warning will be displayed and just the segfault is raised. A workaround is possible via, OMP_NUM_THREADS=1, where both libraries will now work properly.
This may be just limited to macOS weirdness, I have not yet tried on linux yet.
Understandably, this is a unique use case atop of already experimental bindings, so this is more of a heads up.