[Linux] Only setup Mojang JVM on glibc standard C library #110
Comments
|
On |
|
Thank you for this report! The auto JVM install definitely needs a rework for all these edge cases (non-glibc, non-supported os, ...). |
|
One more thing I noticed, it seems the downloaded Results from working Results from broken |
|
Is this only the case with GLFW or with the entire LWJGL suite? Also, I wonder if modifying |
Looks like that is the case, the
Extracting them with The
I'll get back to you if I figure out how this works, installing If you have tips please do tell, I'm not exactly sure what I'm doing right now (and I couldn't figure out how the file(s) end up in |
|
This temporary directory is created by lwjgl itself, it's where all shared objects are extracted from |
|
Well I think I got the game running but believe I've sadly hit issues with the drivers for the hardware as the mainline Linux kernel port for the device isn't quite yet ready for prime time :p Here's the hack of a diff that did the trick ( --- a/src/core/portablemc/__init__.py
+++ b/src/core/portablemc/__init__.py
@@ -775,7 +775,7 @@ class Start:
with open(path.join(bin_dir, native_name), "wb") as native_file:
shutil.copyfileobj(native_zip_file, native_file)
- self.args_replacements["natives_directory"] = bin_dir
+ self.args_replacements["natives_directory"] = "/usr/lib"
self.runner([
*replace_list_vars(self.jvm_args, self.args_replacements),
--- a/src/core/portablemc/cli.py
+++ b/src/core/portablemc/cli.py
@@ -697,6 +697,9 @@ def fix_lwjgl_version(version: Version, lwjgl_version: str):
for lwjgl_os, lwjgl_classifiers in lwjgl_natives.items():
for lwjgl_classifier in lwjgl_classifiers:
classifier_path = f"org/lwjgl/{lwjgl_lib}/{lwjgl_version}/{lwjgl_lib}-{lwjgl_version}-{lwjgl_classifier}.jar"
+ if lwjgl_classifier == "natives-linux-arm64" and (lwjgl_lib == "lwjgl-jemalloc" or lwjgl_lib == "lwjgl-openal" or lwjgl_lib == "lwjgl-glfw"):
+ print_task("WARN", "start.version.system_lwjgl_native", {"lwjgl_lib": f"{lwjgl_lib}-{lwjgl_version}-{lwjgl_classifier}.jar"}, done=True)
+ continue
classifier_url = f"{maven_repo_url}/{classifier_path}"
meta_libraries.append({
"downloads": {
@@ -1172,6 +1175,7 @@ messages = {
"start.version.resolving": "Resolving version {version}... ",
"start.version.resolved": "Resolved version {version}.",
"start.version.fixed.lwjgl": "Fixed LWJGL version to {version}",
+ "start.version.system_lwjgl_native": "Using system provided libraries instead of {lwjgl_lib}.",
"start.version.jar.loading": "Loading version JAR... ",
"start.version.jar.loaded": "Loaded version JAR.",
f"start.version.error.{VersionError.NOT_FOUND}": "Version {version} not found.",
Especially that I had to run with In case of Here's an image of it "running" with the display not refreshing altogether for currently unknown reason with no obvious logs anywhere: |
|
Insane! I'll try to implement all of this in the API, for the CLI I think of a |
Anoying... |
|
It ended up actually being a problem with the custom patched Let me know of any PRs etc. to test that include things I noticed here on both |
|
Another thing about using the system provided native libs: could we somehow make PortableMC pick the correct versioned one (or make user specify it) so we don't rely on unversioned In my case it looks for It would be great if I just tested this theory with the following diff for --- a/src/core/portablemc/__init__.py
+++ b/src/core/portablemc/__init__.py
@@ -776,6 +776,8 @@ class Start:
shutil.copyfileobj(native_zip_file, native_file)
self.args_replacements["natives_directory"] = bin_dir
+ print(bin_dir)
+ input()
self.runner([
*replace_list_vars(self.jvm_args, self.args_replacements),When I now run And pressing enter the game happily launched as well, so we could definitely implement something like this to avoid having to mess with |
|
Speaking of Example: https://github.com/Admicos/minecraft-wayland#step-1-setting-up-multimc-to-use-the-system-glfw |
* Added many arguments both in API and CLI to support fine-grained library exclusion and binaries inclusion. * Added code coverage for test pipeline
* Added many arguments both in API and CLI to support fine-grained library exclusion and binaries inclusion. * Added code coverage for test pipeline
|
@JamiKettunen Released! |
Describe the bug
Mojang JVM binaries/libraries even on non-
glibcsystems where they're useless and don't work.To Reproduce
PortableMC version:
3.1.1Python version:
3.10.8Add-ons:
noneSteps to reproduce the behavior:
portablemc starton Void Linux (musl) or Alpine Linux; the same steps to run work on Void Linux (glibc)Expected behavior
PortableMC should not try to download (and use)
glibc-linked Mojang JVM on e.g.musllibc Linux systems; it should've tried to use thejavaexecutable from$PATHperhaps or make you provide it viaportablemc start --jvm ....One possible solution to avoid downloading and using Mojang's JVM is to check
platform.libc_ver(), as it outputs the following with the different standard C libraries:glibc
musl
Additional context
The text was updated successfully, but these errors were encountered: