Open Frontear opened 1 day ago
This is particularly important for scenarios like flatpak where it is harder to add in the dependency for libGLU
The default cmake structure for effekseer/EffekseerForMultiLanguages only builds shared. This would require updating EffekseerForMultiLanguages to add static builds, and pulling in a static libGLU build as well. Arch, and I believe a majority of other mainstream Linux distros, do not build static libs in their core repos, only shared.
What about providing GLU in the mod assets and loading it from there rather than the standard /usr/lib? I think even that would be more ideal
I think compiling libEffekseerNativeForJava
statically is possibly a better way to go in the long run. That'll allow me to link in all the required objects without having to tote a separate dynamic library. Cmake has a better way of doing what effekseer/EffekseerForMultiLanguages does, I've got a semi-working rework of it's code that builds statically. I'll report in on this as I get closer.
I've generated a new version of the lib with no requirement for libGLU.so
. I had to completely rework effekseer/EffekseerForMultiLanguages to be specific to this scenario, but I've got a clean running version that builds everytime. I'm in testing now, should be up later today.
I was informed by @ripjackie that this mod uses (or effekseer uses)
libglfw.so
andlibGLU.so
, but does not actually provide them, requiring both to be installed system-wide to have an effect.Would it be possible to use the mc
libglfw.so
and statically linklibGLU.so
, or at least provide the shared object within the mod so it can load it in by itself, without requiring users to modify system state? It'd be hard to enforce for people, which is why I think this could be considered an ease-of-use problem.