1.0.2 official Linux release fails to run on Fedora 33

[Calinou]

OS: Fedora 33 x86_64
Bitmapflow version: 1.0.2 official

After extracting all files from the archive and adding the +x executable permission to bitmapflow.x86_64 (which is missing by default), I get this in the terminal:

Godot Engine v3.2.3.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce GTX 1080/PCIe/SSE2
 
ERROR: open_dynamic_library: Condition "!p_library_handle" is true. Returned: ERR_CANT_OPEN
   At: drivers/unix/os_unix.cpp:426.
ERROR: get_symbol: No valid library handle, can't get symbol from GDNative object
   At: modules/gdnative/gdnative.cpp:501.
ERROR: init_library: No nativescript_init in "res://libbitmapflow_rust.so" found
   At: modules/gdnative/nativescript/nativescript.cpp:1506.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
zsh: segmentation fault (core dumped)  ./bitmapflow.x86_64

gdb full backtrace:

#0  0x000000000044a984 in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) [clone .cold.492] ()
No symbol table info available.
#1  0x0000000000000000 in ?? ()
No symbol table info available.

[Bauxitedev]

I think this is because it's trying to load OpenCV but it can't find the library. Do you have OpenCV installed? (Preferably OpenCV 4.2, I'm not sure if it works with other versions)

[Calinou]

Do you have OpenCV installed? (Preferably OpenCV 4.2, I'm not sure if it works with other versions)

I have opencv and opencv-devel 4.3.0 installed. The Fedora 33 repositories don't have OpenCV 4.2.

[Bauxitedev]

Hmm, I don't really have experience with shipping executables for distros other than Ubuntu, so I'm gonna guess the name of the .so files are different on Fedora so it can't load OpenCV. I don't really have the time/experience to maintain a Linux build for every possible distro out there, so do you think it would be possible to somehow statically link OpenCV (a C++ library) in my Rust crate?

On Windows, I solve this issue by just copy pasting all OpenCV dll's and including them with the program, but on Linux this approach seems uncommon. (probably because Windows looks for shared libraries in the executable's own folder by default, but Linux doesn't)

[Calinou]

so do you think it would be possible to somehow statically link OpenCV (a C++ library) in my Rust crate?

This would be the best course of action, but it's probably not easy to link OpenCV statically due to its size and complex build process.

On Windows, I solve this issue by just copy pasting all OpenCV dll's and including them with the program, but on Linux this approach seems uncommon. (probably because Windows looks for shared libraries in the executable's own folder by default, but Linux doesn't)

You could achieve this on Linux with by setting the LD_LIBRARY_PATH environment variable to . when starting Bitmapflow (if you don't compile OpenCV yourself), or change the rpath of the dynamic library (if you compile OpenCV yourself).

The LD_LIBRARY_PATH approach requires a launcher script to work, since it needs to be set every time the program starts:

# bitmapflow.sh
LD_LIBRARY_PATH=. ./bitmapflow.x86_64

[Bauxitedev]

LD_LIBRARY_PATH has potential, I'm playing with it right now. Does LD_LIBRARY_PATH influence Godot itself? E.g. can it cause Godot to fail running because it can't find a dependency it needs for itself, because the dependency folder has changed?

[Calinou]

Does LD_LIBRARY_PATH influence Godot itself? E.g. can it cause Godot to fail running because it can't find a dependency it needs for itself, because the dependency folder has changed?

Using LD_LIBRARY_PATH will also affect Godot itself, but it won't remove any existing dependency links so things should keep working.

[berarma]

I have the same problem on Debian Buster (it has OpenCV 3.2) and I guess it'll be the same when Debian Bullseye (OpenCV 4.5) is released.

Shipping the libraries and a launching script like Calinou's proposed would help a lot of users. It's not an uncommon approach, it's just that there are technically better solutions but they require more work. You have to package it for every distro or build flatpaks, snaps or appimages. Maybe someone gets it on Flatpak before we know it though.

For anyone who might be interested from the future, I was able to run this in a distro that does not include OpenCV 4.2 by using patchelf on libbitmapflow_rust.so.

Using Bash syntax and OpenCV 4.5, adapt as appropriate:

for n in bgsegm bioinspired ccalib dnn_superres dpm highgui freetype fuzzy hdf hfs img_hash line_descriptor quality rgbd saliency shape stereo structured_light phase_unwrapping superres optflow surface_matching tracking text dnn plot ml videostab videoio ximgproc xobjdetect objdetect calib3d imgcodecs features2d flann xphoto imgproc core
do patchelf libbitmapflow_rust.so --replace-needed libopencv_$n.so.{4.2,4.5}
done