Open MrCyjaneK opened 10 months ago
Thanks for reporting!
Failed to load dynamic library 'libobjectbox.so': libobjectbox.so: cannot open shared object file: No such file or directory
This sounds like the shared library isn't bundled at all. It should be in a lib
folder next to the executable.
Can you
flutter pub upgrade objectbox --major-versions
)?Hey! The lib is at the right place - I've tested it on a just created flutter project. As can be seen in the ldd - the file is there.
My dependencies are exactly the same as in getting started (with latest versions from pub.dev).
This could be relevant:
libstdc++.so.6 => not found
We don't test on NixOS, so I'm sorry that we cannot really help here. This is extremely common lib with Linux, so my guess that this is a very NixOS-specific issue. Let us know if you find something out.
Okay! I'll investigate that further and let you know about the details!
I am not familiar with how flutter packaging works, but I packaged the objectbox-c
pre-built shared object for nixos (see gist).
I am able to get apps running if I manually delete lib/libobjectstore.so
and then symlink in the patched binary from the nix store. However, when I rebuild it seems to get overwritten as the cmake file always re-downloads the prebuilt binary. As I am not familiar with flutter packagingI am not sure best practice for updating the cmake file to allow me to "bring my own shared object."
@jordanisaacs I think that a flag for building objectbox as a part of flutter build is they way to go - but I'm unsure what's the objectbox team on that.
I don't follow; e.g. what's "the patched binary from the nix store"?
If you do not want the CMake setup, you can e.g. go with download.sh - there's a tab for that in the installation docs. And/or, copy and adjust the CMakeLists.txt for your needs?
the patched binary from the nix store is output of the nix expression posted by @jordanisaacs. (p.s. I couldn't get it to work with nix-build).
And I think that I'll speak for me and other nix users who use objectbox - we wouldn't really want to manually adjust the CMakeLists.txt in every project because we are already using objectbox_flutter_libs
and it should provide the system system with binary it can run.
also I've just realized that objectbox is closed source.. truly a good job at obfuscating that fact.. And since using closed source code is a blocker for me I guess that I'll need to find some other database that doesn't hide the (quite important imo) fact about the project source being unavailable.
also since we are here already - could you change licensing on https://pub.dev/packages/objectbox? This is a bit misleading - mentioning that you also accept the objectbox binary license would be a cool thing. p.s. I'm unsubscribing from this issue, so ping me if you need something from me.
I don't follow; e.g. what's "the patched binary from the nix store"?
If you do not want the CMake setup, you can e.g. go with download.sh - there's a tab for that in the installation docs. And/or, copy and adjust the CMakeLists.txt for your needs?
The issue is NixOS doesn't have its shared libraries in the standard Linux location. Hence you see missing libraries with ldd.
that Nix expression I wrote patches your pre-built shared object to point to the other shared objects correctly (using autopatchelf), but it also places it in the nix store /nix/store/*****
. Furthermore nix builds software in a sandbox without network access.
I think all I need as a packager is for objectbox to provide an environment variable that skips downloading the shared object in the build phase. My goal is to package BlueBubbles for Nix which utilizes this library, and it would also make life easier packaging anything else that utilizes this library .
@jordanisaacs Thanks for providing some background!
Had a quick look... CMake offers providing some "patch command" (docs here, search for "PATCH_COMMAND"). If there would be a way to "inject" (e.g. env var?) a patch command from your side, would you be able to run autopatchelf and do the adjustments? This would also cover updating to a new version and stuff; might be a smoother (more automated) process?
Basic info:
Steps to reproduce
Expected behavior
App would run
Code
N/A
Logs, stack traces
To fix the issue I tried..
but it didn't work. I thought that the issue may be with flutter run overriding the LD_LIBRARY_PATH - so I've decided to test it another way:
But it still doesn't work