Skip to content

Multi-arch patching support #14

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

Closed
wants to merge 4 commits into from
Closed

Multi-arch patching support #14

wants to merge 4 commits into from

Conversation

ViRb3
Copy link
Contributor

@ViRb3 ViRb3 commented May 18, 2022

Introduces multi-arch patching support, so unsupported architectures can have their libraries swapped with fixed versions. Initially implements support only for macOS arm64 (M1), but is easily extensible for more. The PR also brings some changes to the docs and tooling to allow new contributors to get started more easily. The allow/block list approach for lwjgl has also been replaced with a generic algorithm that will find the newest variant with all required native libraries.

The M1 libs come from ManyMC's meta: https://github.com/MinecraftMachina/meta-multimc-arm64/blob/5723d4fd60e4ef7ed6c78f1fef29f01c4ad0ecca/org.lwjgl3/3.3.1.json

Check out the generated meta here: https://github.com/ViRb3/meta-polymc. For some reason, the "auto choose lwjgl variant" commit ends up replacing the suggested lwjgl version for 1.14 pre-release: https://github.com/ViRb3/meta-polymc/commit/b1e9f22837f2e3b7963d36c600d7e04c6719bd0a, but this may be okay. Should investigate. This PR won't work with the launcher yet, since rules with os architecture suffix are not supported yet. Something like PolyMC/PolyMC#514 is necessary.

The general idea is to replace all necessary libs using rules that have an architecture suffix on the os property:

     {
         "downloads": {
             "artifact": {
                 "sha1": "9fab79a2822f493b194c81f5c92d3466abc28f27",
                 "size": 10810,
                     "url": "https://libraries.minecraft.net/com/mojang/text2speech/1.10.1/text2speech-1.10.1.jar"
                 }
         },
         "name": "com.mojang:text2speech:1.10.1",
+        "rules": [
+            {
+                "action": "allow"
+            },
+            {
+                "action": "disallow",
+                "os": {
+                    "name": "osx-arm64"
+                }
+            }
+        ]
     },
+    {
+        "downloads": {
+            "artifact": {
+                "sha1": "f378f889797edd7df8d32272c06ca80a1b6b0f58",
+                "size": 13164,
+                "url": "https://libraries.minecraft.net/com/mojang/text2speech/1.11.3/text2speech-1.11.3.jar"
+            }
+        },
+        "name": "com.mojang:text2speech:1.11.3",
+        "rules": [
+            {
+                "action": "allow",
+                "os": {
+                    "name": "osx-arm64"
+                }
+            }
+        ]
+    }

@Scrumplex
Copy link
Contributor

Mojang chose to ignore the whole architecture stuff and just ship natives for an OS no matter the actual arch. So macOS will download both x64 and arm64 natives.
I would propose copying that solution. Though this will require changing the layout of the natives jars

@Scrumplex
Copy link
Contributor

This is how new natives archives look now:

natives diff

Scripts to generate jsons and jars that PolyMC will access.

## Deployment
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason we only "support" Docker is because of some weirdness when running this on different machines. Some machines produce different output, so the Docker container is there to minimize differences in the environment.

@Scrumplex Scrumplex mentioned this pull request Jun 26, 2022
5 tasks
@Scrumplex
Copy link
Contributor

Closing this in favor of #16

@Scrumplex Scrumplex closed this Jul 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants