cockpit-project / cockpit-files

A Featureful File Browser for Cockpit (Modernized and tested version of https://github.com/45Drives/cockpit-navigator)
GNU Lesser General Public License v2.1
46 stars 25 forks source link

Build Arm64 #609

Open shortyishere opened 3 months ago

shortyishere commented 3 months ago

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 commented 3 months ago

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 https://github.com/cockpit-project/cockpit/issues/20220

allisonkarlitskaya commented 1 month ago

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 https://github.com/nodejs/loaders/issues/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). https://github.com/nodejs/node/pull/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 commented 1 month ago

@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 commented 1 month ago

I said tsx, not tsc :)

martinpitt commented 1 month ago

@allisonkarlitskaya ah, first time I hear about tsx -- that's ./build.js's #!/usr/bin/env -S node --import tsx/esm. I see commit e1664765bc8de, 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 commented 1 month ago

@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 https://github.com/cockpit-project/cockpit-files/pull/536 and https://esbuild.github.io/getting-started/#simultaneous-platforms

Patrick-1-1-1-PH commented 1 month ago

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

jelly commented 1 month ago

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