Does bun support cross-compilation?

[timfayz]

What is the type of issue?

Documentation is missing

What is the issue?

Bun offers the ability to compile (embed) a script file into a standalone executable. However, the documentation does not explicitly mention (nor does bun build) that the compiled binary can only run on the system it was built. Additionally, there is no information about whether bun supports cross-compilation, such as building an executable on macOS for Windows and whether it is possible to embed not only the entry point script but also, say, an image that is being served by the script. Although cross-compilation is a separate, complex topic and probably out of scope, a simple "supported platforms" section on the documentation page (or in bun build) is something most users (like me :)) would expect to see.

Where did you find it?

https://bun.sh/docs/bundler/executables

[Jarred-Sumner]

No cross-compilation, though not super hard to add -> Linux (to macos is harder)

Assets can be embedded via importing files into the bundle and then to read, using either Bun.file(defaultImporyOfAsset) or readFile from node:fs

We need to add docs for this (cc @colinhacks)

https://twitter.com/jarredsumner/status/1673021722671583232?s=46&t=0Uhw6mmGT650_9M2pXUsCw

[objectivecosta]

@Jarred-Sumner I see that the compile command basically merges selfExePath with the assets of the source. Could cross-compiling be achieved by doing that with another platform's bun binary? If so, I can get on it.

[jackyzha0]

Hey! Wondering if there was any news on this? This would be helpful in having better devex around using Bun in production at Replit (specifically MacOS -> Linux)

[samheutmaker]

+1 on this being huge for using bun in production. Having to run a separate build processes for each architecture makes CI a pain.

[dgpt]

+1 on this - I'm using bun to create a cli, it would be awesome to have a binary executable available for every OS.

[silverwind]

Another related problem with bun build on linux is that the binaries it produces are dynamically linked to a few libs like libc, so they are not truly portable across linux distributions and/or releases. Maybe an option like --static could be added to produce static binaries.

$ bun build foo.js --compile --outfile foo
$ ldd foo
	linux-vdso.so.1 (0x00007fff83daf000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x000073ff36237000)
	libm.so.6 => /usr/lib/libm.so.6 (0x000073ff3614b000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x000073ff36146000)
	libc.so.6 => /usr/lib/libc.so.6 (0x000073ff2f81e000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000073ff3625e000)

[benduran]

Subscribed for updates. I'd be happy to be a guinea pig on this!

[Jarred-Sumner]

Another related problem with bun build on linux is that the binaries it produces are dynamically linked to a few libs like libc, so they are not truly portable across linux distributions and/or releases. Maybe an option like --static could be added to produce static binaries.

$ bun build foo.js --compile --outfile foo
$ ldd foo
	linux-vdso.so.1 (0x00007fff83daf000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x000073ff36237000)
	libm.so.6 => /usr/lib/libm.so.6 (0x000073ff3614b000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x000073ff36146000)
	libc.so.6 => /usr/lib/libc.so.6 (0x000073ff2f81e000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x000073ff3625e000)

Currently, we aim to support glibc v2.28 which was released almost 6 years ago. The other linked libraries are included in ~every non-musl Linux distribution. This is a good balance of supporting the vast majority of Linux while still allowing us to use modern Linux features in performance optimizations. If we wanted to reduce binary size, we could dynamically link libicu and shave off about 38 MB of Bun's Linux build, but we do not since it's confusing which version of libicu to install

A fully static build is unlikely until we support musl. Static glibc doesn't work well.