Skip to content
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

Build Arm64 #609

Open
shortyishere opened this issue Jun 28, 2024 · 8 comments
Open

Build Arm64 #609

shortyishere opened this issue Jun 28, 2024 · 8 comments

Comments

@shortyishere
Copy link

You installed esbuild for another platform than the one you're currently using.
This won't work because esbuild is written with native code and needs to
install a platform-specific binary executable.

Specifically the "@esbuild/linux-x64" package is present but this platform
needs the "@esbuild/linux-arm64" package instead. People often get into this
situation by installing esbuild on Windows or macOS and copying "node_modules"
into a Docker image that runs Linux, or by copying "node_modules" between
Windows and WSL environments.

@jelly
Copy link
Member

jelly commented Jun 28, 2024

Copying node_modules between architectures is indeed not supported, are you on an Aarch64 platform trying to develop something for files?

We have had some discussion about aarch64 in the past here cockpit-project/cockpit#20220

@allisonkarlitskaya
Copy link
Member

I'm reasonably sure I know why our usual wasm tricks aren't working here: tsx vendors its own copy of esbuild, and it doesn't include the wasm one.

The important parts of nodejs/loaders#217 are already complete. We can use this (with a few adjustments) once the (already released) Version 22.6.0 makes it into Fedora (and we include it in our tasks container). nodejs/node#54283 also landed (which would let us do this with no code changes at all) but so far it hasn't made it into an upstream release yet.

So, in short: I think we'll have a solution to this issue soon enough.

@martinpitt
Copy link
Member

@allisonkarlitskaya But we don't (or shouldn't) call tsc during a normal make, do we? I thought that was only during test/static-code, and regular esbuild would just filter out the type annotations. Having yet another bundled copy of esbuild is annoying (and outright stupid -- what does tsc care about what bundler the project uses?), but I don't see how it breaks that? Or do we need to fix our build system?

@allisonkarlitskaya
Copy link
Member

I said tsx, not tsc :)

@martinpitt
Copy link
Member

@allisonkarlitskaya ah, first time I hear about tsx -- that's ./build.js's #!/usr/bin/env -S node --import tsx/esm. I see commit e166476, so this is only for this file type plugin (which isn't really critical). Now I understand why this doesn't affect other projects.

I still don't understand why our aarch64 packit test works, and doesn't run into this issue.

@jelly
Copy link
Member

jelly commented Aug 19, 2024

@martinpitt Because they never really build node_modules, do never build anything. We tried to build things on aarch64 but that turned out to be a disaster as node_modules cannot be shared across architectures which is what node-modules.git does.

See #536 and https://esbuild.github.io/getting-started/#simultaneous-platforms

@Patrick-1-1-1-PH
Copy link

source code failed to compile due to mismatch in processor architecture. this is a bug?

@jelly
Copy link
Member

jelly commented Aug 31, 2024

I assume that's due to the node_modules git clone you have locally? It is build on x86 and not compatible with ARM sadly. My suggestion is:

rm -r node_modules
npm install
./build.js

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

No branches or pull requests

5 participants