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

Android ARM binaries #2335

Closed
ravener opened this issue Jun 21, 2022 · 6 comments
Closed

Android ARM binaries #2335

ravener opened this issue Jun 21, 2022 · 6 comments

Comments

@ravener
Copy link

ravener commented Jun 21, 2022

issue #803 included support for android arm64 builds. I'd like to suggest arm 32-bits as well.

I can build esbuild from source no problems and this is not a big deal for me but for completeness sake I believe ARM should be supported too.

@evanw
Copy link
Owner

evanw commented Jun 21, 2022

Cross-posting from #1578 (comment)

I'm closing this as I don't want to complicate esbuild's deploy process by having to install the entire Android build toolchain for this one platform. All of the other 18 platforms I already support can be built fine by Go on any platform without installing anything. I still don't understand why Go doesn't support cross-platform builds for this platform in particular (Go and Android are even both Google projects!) but that's up to them I guess. If you want to run esbuild on 32-bit Android ARM, you'll have to build it yourself. Sorry.

@evanw evanw closed this as completed Jun 21, 2022
@ravener
Copy link
Author

ravener commented Jun 22, 2022

@evanw it seems like go enforces CGO_ENABLED for android and the generated binaries are dynamically linked, pointing to /system/bin/linker(64) instead of statically linked.

to be fair since the linux binaries are statically linked they do run fine on Android it's just that platform resolves to 'android' rather than 'linux' so another option would also be to just alias those and publish the linux binaries as android, it would atleast suffice for use in Termux.

otherwise, completely understandable, I respect your decision and I'm completely fine with building from source.

@lojosan
Copy link

lojosan commented Aug 23, 2022

@evanw it seems like go enforces CGO_ENABLED for android and the generated binaries are dynamically linked, pointing to /system/bin/linker(64) instead of statically linked.

to be fair since the linux binaries are statically linked they do run fine on Android it's just that platform resolves to 'android' rather than 'linux' so another option would also be to just alias those and publish the linux binaries as android, it would atleast suffice for use in Termux.

otherwise, completely understandable, I respect your decision and I'm completely fine with building from source.

This would be really nice, as installing esbuild (or tools that depend on it, like Vite!!) in Termux on ARMv7 (32-bit Android) is impossible unless building it from source, which I have not tried yet.. and in the case of Vite, it appears to install (for example, pnpm add -g vite) fine but then fails in postinstall due to unsupported architecture.

@Freed-Wu
Copy link

Android termux has supported esbuild termux/termux-packages#11873

Can we:

  1. If user doesn't have esbuild in Android termux, when they npm install esbuild, give a warning and let them pkg install esbuild
  2. If user has esbuild in Android termux, use it and give an information about it, not give an error

@ravener
Copy link
Author

ravener commented Apr 15, 2024

Android termux has supported esbuild termux/termux-packages#11873

Can we:

1. If user doesn't have esbuild in Android termux, when they `npm install esbuild`, give a warning and let them `pkg install esbuild`

2. If user has esbuild in Android termux, use it and give an information about it, not give an error

Unfortunately, that wouldn't be simple, the npm package was made for that reason to make it OS-independent so it can't make use of your package manager, and your package manager (at least how Termux packages them) can't guarantee a specific version either like the npm package could.

@Freed-Wu
Copy link

At least we can ignore the error to ensure esbuild node package can be installed. Then user can ln -s $(which esbuild) node_modules/.bin to use it. For a specific version, user should ensure it by themselves, if them meet any problem because they use system's esbuild not npm's, they should take the duty by themselves.

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

4 participants