-
Notifications
You must be signed in to change notification settings - Fork 58
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
Mac arm64 binaries are bad because the pipeline installs x64 .NET #179
Comments
I was trying to use this to call some C# code from nodejs. The objective is to deploy this in a linux container but I'm developing on a Mac with an arm cpu. I replaced the binaries in the npm package with some I built myself and I managed to call System.Console.WriteLine. But then when I was trying to build a C# library with some stuff annotated with [JSExport] the binaries in the microsoft.javascript.nodeapi.generator package seem to be Windows only. I hope that helps. |
That package is supposed to be platform-independent, as it is an MSIL assembly. But due to this issue we haven't been able to test on Mac arm64 so maybe it's not correctly built to be fully platform-independent. |
And this is the error I get when I try to build a csharp library with the NodeApi packages:
|
Happy to test things if it helps. |
Update: I found the right people on the Azure DevOps team and got them to look at this issue. A fix for the pipeline task bug was merged yesterday. The release process for the new pipeline task version will take a couple weeks. After that we should be able to just update our pipeline task and finally have a good Mac arm64 build. |
@luanmm Is the Docker container OS Linux? This issue is specifically about arm64 on Mac OS. It doesn't affect arm64 builds for Linux.
Obvious question, but have you checked whether the file |
I'm using a Linux host on amd64 targetting a Linux on arm64. This is a simple use case, only in .NET/C# (I'm not working with interop from the JS side). But indeed, the dll seems not to be produced actually. The "misleading error" that I stated is because I would expect that an error that is not producing the output should be thrown before (in the build, for instance). I could not understand why it happened. I can dig a little deeper if needed/helpful. |
Oh, now I found this: #80. Perhaps the problem is indeed the Linux arm64 version not being published yet in Nuget package? 😄 If so, just sorry for mixing up the subjects here! |
I'm actually not sure about the status of Linux arm64 builds. Regardless, the error you reported is related to a platform-neutral (MSIL) assembly file, so it might not be related to the arm64 platform anyway.
Please open a separate issue if you want to continue troubleshooting. And if you do, include more information about how your project is organized, built, packaged, and deployed. |
@jasongin @vmoroz It seems like the Azure pipeline bug was merged a couple of weeks ago. Were the OSX ARM64 binaries fixed for node-api-dotnet ? |
@jasongin @vmoroz Thanks for fixing the build, I tried using version 04.34 on mac osx ARM64, but got the below error.
|
It looks like related to the missing dlls for other architectures on NuGet. If you reference the local dlls of the NPM package, you migh get further. |
@coding-velociraptor Yes, when I built the library on my local using |
This is really looking the same scenario as I'm having here when building my project for ARM64 (even though I'm on a Linux OS) - I'm developing in an AMD64, but publishing the project in an AWS Graviton (which uses ARM64 arch). Locally, the Nuget package works (in an AMD scenario), but in AWS it is broken (ARM scenario). My workaround, for now, is doing a clone in the |
We know the published Mac arm64 build still isn't functional. @vmoroz recently updated the build agent to arm64, but that triggered another problem. |
Fixed in v0.5.10. |
Opening a separate issue to track this, after discussion in comments of #56.
The root cause is a bug in the .NET install task that the Azure DevOps build pipeline uses. We should be able to work around that by using a different method to install .NET, such as the install shell script.
The text was updated successfully, but these errors were encountered: