-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancment request, Crash on arch due to spdlog/fmt #180
Comments
What's the problem? I've tried to run j4-dmenu-desktop in an Archlinux docker container and it seems to execute properly. I am not an Archlinux user, so my comments should be taken with a grain of salt, but this looks like a result of a partial upgrade. Does If you do not trust your shared libraries, you can build j4-dmenu-desktop's dependencies statically. The easiest way to do this is by building j4-dmenu-desktop as follows: meson setup --buildtype=release -Db_lto=true --force-fallback-for=spdlog,fmt build
# This downloads and links deps manually: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# And then continue with normal Meson build steps documented in README... If you happen to have static libraries of spdlog or fmt at hand, you can instruct Meson to use them1 using Meson's standard flags ( Similar results should be achievable with CMake, but I don't know its flags for this of the top of my head. The solution you are proposing (continue functioning if there is an error while loading shared libraries) would be pretty difficult to implement and fairly nonstandard. It is reasonable to expect the program to fail if there are problems with shared libraries. Deviating from this behavior could surprise users. Footnotes
|
i did a full upgrade again and i'm still getting crashing which was my motivation aside, i also belive that deps should be optional whenever possible. although if this is mountains of work, feel free to close. |
i'd just like a way to not require the dep, i don't actually need it to catch errors. dependency hell is something i've been in for too long, so i have a tendency to prefer not having them at all, regardless of lost functionallity. (and this is the sole issue i've had with j4-dmenu-desktop and it isn't even it's fault. so i don't think i'd miss the logger) |
I think that there are two choices made by j4-dmenu-desktop that are related to this:
|
Also, you appear to be aware of this, but I should reiterate that I hold no responsibility over Archlinux's By using your distribution's package, you are putting your trust into its maintainer's hands. They are responsible for that package on their distribution. You should probably report this to Archlinux. |
I have looked this up and the "Try to load dynamic libraries, but don't require it if it can't be loaded during runtime |
i mean a lot of programs have optional deps that are checked at runtime i don't find this a fringe situation. obs for example. i'm also happy to reiterate this is entierly a badly managed package repo with loosely defined deps and nothing at fault with the project. i'd just like the program to be robust against badly managed package repos if possible, and i also understand that silent failiure being a default behaviour is bad. i'd still like to have the simplicity of using the package provided by the default repo. without the possibility of booting my system and only having terminal access and i trust j4-dmenu-desktop to remain functional enough to not have logging for it.
i don't like the arch maintainers, they have repeatedly caused issue and been very loose with defining deps by choice. they'd probably fix this at least, don't trust them to keep it fixed though. i just like pacman, if i knew of a good repo maintainer for it i'd switch. again thought you can just not deal with this, that's fine.
but if you've got an easy way to add a robust mode i'd certanly be apriciated |
I recognize this is no fault of yours.
Arch currently packages fmt11 and spdlog which is looking for fmt10. this is entierly an arch issue, but anychance you could not crash if the logger doesn't load? it's very annoying having the primary method of opening apps be broken because package maintainers goof.
The text was updated successfully, but these errors were encountered: