[bug] Problems with adding shared libraries
Describe the bug
I have a c++ external binary that depends on tensorflow's shared lib (dll on windows, .so on linux), I want to make sure and be pretty sure that the shared libs are always on the same level of the that binary or else it will either be stuck and will seem that it is running infinitely or it will return: libtensorflow.so.1: cannot open shared object file: No such file or directory.
Keeping in mind: this only happens on release when using an installer like msi or .deb, because when i run the debug version npm run tauri dev, it works fine without any problem.
Here is the config:
// Resources contains the shared libs
"resources": {
"resources/*": "",
},
// The c++ bin itself
"externalBin": ["bin/externalBin"],
Reproduction
No response
Expected behavior
I want the shared libs to be in the same level as the external binary.
Full tauri info output
[✔] Environment
- OS: Fedora 40.0.0 x86_64 (X64)
✔ webkit2gtk-4.1: 2.46.1
✔ rsvg2: 2.57.1
✔ rustc: 1.82.0 (f6e511eec 2024-10-15)
✔ cargo: 1.82.0 (8f40fc59f 2024-08-21)
✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
- node: 20.17.0
- npm: 10.8.2
[-] Packages
- tauri 🦀: 2.1.1
- tauri-build 🦀: 2.0.3
- wry 🦀: 0.47.0
- tao 🦀: 0.30.8
- tauri-cli 🦀: 2.1.0
- @tauri-apps/api : 2.1.1
- @tauri-apps/cli : 2.1.0
[-] Plugins
- tauri-plugin-process 🦀: 2.0.1
- @tauri-apps/plugin-process : 2.0.0
- tauri-plugin-fs 🦀: 2.0.3
- @tauri-apps/plugin-fs : 2.0.2
- tauri-plugin-notification 🦀: 2.0.1
- @tauri-apps/plugin-notification : 2.0.0
- tauri-plugin-updater 🦀: 2.0.2
- @tauri-apps/plugin-updater : 2.0.0
- tauri-plugin-os 🦀: 2.0.1
- @tauri-apps/plugin-os : 2.0.0
- tauri-plugin-dialog 🦀: 2.0.3
- @tauri-apps/plugin-dialog : 2.0.1
- tauri-plugin-shell 🦀: 2.0.2
- @tauri-apps/plugin-shell : 2.0.1
[-] App
- build-type: bundle
- CSP: unset
- frontendDist: ../dist
- devUrl: http://localhost:1420/
- framework: React
- bundler: Rollup
Stack trace
No response
Additional context
No response
Any updates? Is there any required info I forgot to mention here in this issue?
there's no direct support for that but on windows you can use the resources config (in object notation to get the dlls next to the exe) and on linux and macos the files config should work (though the lib can't be next to the executable on those platforms but in the lib dirs).
I wanted to work on a cross-platform dylib feature/config for ages now but never got to it.
config should work (though the lib can't be next to the executable on those platforms but in the lib dirs).
Do you mean /usr/lib? So the solution is to either link to this directory or use the files config? Thanks.
On linux, yes (though it should probably be in sub directories). On macOS it's .app/Frameworks/ i think.
I'm not sure what you mean with linking to it, i thought about this: https://v2.tauri.app/distribute/debian/#custom-files with /usr/lib/x86_64-linux-gnu/<appname> (for rpm with the x86... part i think) instead of /usr/share. I'm not sure if that really works though tbh.
I'm not sure what you mean with linking to it
I mean linking the binary with the shared lib when compiling it
In other words: telling the binary where to look for the shared library
I am also looking forward to a similar feature, as I need to bundle the Python interpreter in tauri-apps/tauri#11883.
I mentioned more information in WSH032/pytauri#3 and implemented bundling the Python interpreter on Windows in WSH032/pytauri@d5952b3c9d0abe1418c93fdbf4e6dcbab72760c9. Here is the Documentation.
Using the resources config to bundle dynamic libraries is quite painful for me. You can see the NOTE I added in the Documentation.
I hope tauri can add some documentation on how to bundle shared libraries on Linux and macOS.
any updates on how to use an included local lib
Not from our side at least. idk about the community 🤷
how are people doing it now? modifying the path? is there a decent hacky way?