Support for Apple Silicons architecture aarch64/arm64 #154
Comments
|
the best solution I can think of right now is adding a configurable override on what's to be fetched, that'd mean you'd have to write the logic for determining what to pick in your build script. |
|
We are considering enabling download by default at jhipster. It should fetch amd64 instead of arm64. |
That would be lovely .. node {
version.set("12.18.4")
npmVersion.set("6.13.7")
download.set(true)
fullPathToResource.set("https://nodejs.org/dist/v12.18.4/node-v12.18.4-darwin-x64.tar.gz")
}depending on architecture .. or to hacky? |
|
@fkfhain I'm thinking something more along the lines of node {
nodeArchitectureOverride.set({
if (Os.isFamily(Os.FAMILY_MAC)) {
return "darwin-x64"
}
return null
})
} |
|
Just to be sure I understand what is happening here. We detect that the system is a macOS running on a arm architecture but the corresponding Node.js bundle does not exist yet so the download fails. The workaround is to install the x64 version that is supported by Apple Silicon system thanks to the emulator, but we cannot add that to the configuration. Am I right? If this is true, should not we take this into consideration when determining the platform for which we download the bundle? |
|
The only two arguments I can think of going against it is that: 1. it's work and 2. if we don't offer a way to override that using a custom repo which does contain a node built for arm-Macs we'd have no way of making use of that. |
|
Is it more complicated than returning You mean you would want to make it possible to override it for people using custom Apple Silicon builds? I don't know this topic very well, but it sounds like we should handle this specificity on our side in order to support Apple Silicon systems out of the box. When the Apple Silicon build is available, we will be able to adapt the detection mechanism to use the right architecture if available. For that we could use the Node.js version. For instance if we assume it will be supported in Node.js 16 and not below, we could state that we use the x64 bundle for Node.js < 16 and the arm bundle for Node.js >= 16. What do you think about that? |
|
I tried messing around with We should just handle it on our end |
|
Thanks for looking into this. Highly appreciated. Just to clarify: The problem is that the construction of the download url Obviously those packages (darwin + mac) don't exist for all the (older) nodejs versions out there. So .. 404. Hence the suggestion to provide an override-url that downloads and attempts to execute the packaged regardless of recognized architecture on the build client. |
|
Can someone tell us what the I am pretty sure that we can fix that quite easily by forcing to return |
|
os.arch -> aarch64 But overriding this on a global level definitely has probably undesired side-effects .. |
|
I changed the platform detection behavior to return Here is how to test that. First, checkout this repository, switch to the
Hope this will work! I don't think that this will have undesired side effects since the code I modified is only used to determine which Node.js bundle to use. |
|
@bsautel .. I did both. Mixed results: As for When running with --info a warning is printed But I'm unsure if that warning is related .. |
|
Thanks for you quick answer. Our integration tests are unfortunately very unstable. That sometimes the case on my laptop but it happens much more frequently in GitHub Actions. That's really painful, it's the reason why we retry multiple times the failing tests. We can see tests failures in the terminal but the build does not fail. I don't know why, when I run some Node, The first error you have is probably an integration test that failed, that has nothing to do with this issue. The second one seems to be related to what I changed. It sounds like it is a warning indicating that a test failed, but it is not a Gradle test failure report. On my side, all the tests are passing, and it is also the case in GitHub Actions on Windows, macOS and Linux. I'll have a look at that but the fact that the tests passed and your real life project test also succeeded seem to show that it fixed the issue. @deepy what do you think of this fix proposal? |
|
@bsautel I've tried option with It says, that it cannot find I have an assumption, that for yarn project the relative module path is resolved wrong in M1 for some reason (same build is success on Intel chip mac). Please let me know if you need more details or you'd like to have a separate issue for it, thanks. |
|
Thanks @seregamorph for your confirmation that the download now works and for the working directory issue report. It don't really see why an architecture change would lead to break this kind of thing but the issue you are reporting is quite similar to #152 in which npm is in the PATH but the Gradle plugin cannot find it when running a Could you try something to check whether the issue comes from a wrong working directory? Add a task to your project like this (Groovy DSL, ask me if you need some help to convert it to Kotlin if your build is in Kotlin)? task env(type: NodeTask) {
script = file("env.js")
outputs.upToDateWhen {
true
}
}Create a console.log(`Current working directory: ${process.cwd()}`);Then run the |
|
Project root (multimodule): /Users/morph/Projects/acme/acme-codeserver-framework Module (with new task): env.js location: Command: Result contains: (if the env.js file is located in other directory, the build fails) |
|
The current working directory variable seems to be right. 🤔 In issue #152 we discovered that the issue related to the |
|
If anyone works at a company that makes obscene amount of monies this is the perfect time to sponsor either/both of us with a M1 Mac ;-) Or perhaps with some M1-as-a-Service that we can add to our CI pipeline like the one from scaleway, or just SSH access to a M1 mac |
|
@bsautel the same result (to ensure, I've stopped the daemon first): P.S. @seregamorph is my second (personal) account |
|
Ok. And what if you manually run the command the Gradle plugin is supposed to run. By default the working directory is the one of the project (not the root project). Does it run? Sorry for all these questions, but I am trying to identify the cause of this issue and I don't have any Mac M1 computer. |
|
@seregamorph on my gmail I only have oddly specific targeted spam and I can't see anything in the main inbox |
|
@deepy okay, whatever. Can you please contact me to serega.morph[at]gmail.com, I'm ready to suggest some options regarding rent M1 machines. I'd like not to discuss it here. |
|
I still do not see any answer on my e-mail, probably the spam filter is stubborn (please check your spam folder, maybe you'll find smth interesting :D ) |
|
@seregamorph thanks for your great proposition! I did not have time to reply before. I replied to your email. @deepy it sounds like it was sent to your personal gmail address. |
|
FYI for anyone finding this issue and who can afford to use node v16: |
|
Temporary Fix: Duplicate your terminal in the finder app. Open the info and enable the rosetta. Run the "arch" command to confirm that you are running in i386. Install the brew app and then using brew install the adoptopenjdk11 for example. Run the "java -XshowSettings:properties -version" command and confirm that the "os.arch" is "x86_64". Now compile your app and the gradle node plugin will use the "x86_64" arch. |
|
I think we might want to change the default node version to 16 (even though it's not LTS) Thanks for the workaround JnManso, that's going to help a lot of people who can't upgrade :-) |
|
The solution proposed doesn't work with tools like |
|
Found it! I run my task with the following parameter, to bypass the current os arch. I know it's not optimal for a lot of other things… but 🤷, I can't do anything else, the front is stuck in old node… and especially |
class Process {
public static void main(String[] args) throws Exception {
var process = new ProcessBuilder("sysctl", "sysctl.proc_translated").inheritIO().start().waitFor();
System.out.println(System.getProperty("os.arch"));
}
}And the underlying issue being that |
When building modules using gradle-node-plugin I do get:
Could not find org.nodejs:node:12.18.4.
Searched in the following locations:
- https://jcenter.bintray.com/org/nodejs/node/12.18.4/node-12.18.4.pom
- https://repo.maven.apache.org/maven2/org/nodejs/node/12.18.4/node-12.18.4.pom
- https://nodejs.org/dist/v12.18.4/node-v12.18.4-darwin-arm64.tar.gz
Enviroment:
Any plans to incorporate aarch64/arm64 support in upcoming releases?
Or
Any ideas on how to enforce a download for ~x64 versions of node (which will run in rosetta2-comp mode)?
Thanks a lot.
The text was updated successfully, but these errors were encountered: