target x86_64-unknown-linux-musl

[hayd]

It would be great to build/publish this as a target (for alpine and other platforms without glibc, iiuc).

It already seems to build okay (--target x86_64-unknown-linux-musl).
(see also denoland/deno#3711 (comment))

It's unclear to me if it's best to only target x86_64-unknown-linux-musl or to additionally support it. e.g. sccache seems to only provide binaries for that target.

[kesor]

If anyone is interested, I have compiled DENO with V8 in Alpine Linux Docker container - without glibc, but completely using the Alpine muslc library.

https://gist.github.com/kesor/68df53a5d76784a235ca6b0e7efed4d9

Enjoy!

[theoparis]

Any updates on this? It's been 2 years ... I need musl support in order to embed deno into my linux kernel-based system because it needs to be linked statically with no /lib/*.so dependencies.

[kitsonk]

Just because something is open doesn't mean that a) it is being actively worked on or b) set any expectations about it being closed, especially when it comes to open source software.

I am sure a contribution in this area would be welcome.

[localhosted]

I'm trying to build a static Edge Runtime but I'm new to Rust. Where could I start to attempt to build deno statically?

[groboclown]

I'm attempting to work my way through what it takes to build on musl. Part of this comes from having issues just getting the static build to work, regardless of musl or glibc.

My current approach runs the build inside a container to ensure it's reproducible. For those playing the home game, I'm running off the base image docker.io/rust:latest, which builds off an Ubuntu distro.

I start off easy:

$ apt-get update && apt-get install -y musl-tools musl-dev libclang-dev clang
$ rustup target add x86_64-unknown-linux-musl
$ cd /tmp
$ cargo init v8test
$ cd v8test
$ cargo add v8
$ rustup component add rustfmt
$ V8_FROM_SOURCE=1 cargo build --target x86_64-unknown-linux-musl --release -vv
(snip)
  --- stderr
  ninja: error: '../../../../../../usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/v8-0.106.0/third_party/icu/common/icudtl.dat', needed by 'icudtl.dat', missing and no known rule to make it

This is the old error reported in other issues. I use an ugly work-around to get past it: I replace the Rust cache version of the v8 repository (which explicitly omits items) with the full Git version:

$ v8_src="$( readlink -f /usr/local/cargo/registry/src/index.crates.io-*/v8-0.106.0/)"
$ rm -r "${v8_src}"
$ git clone --depth 1 -j8 --recurse-submodules --branch v0.106.0 https://github.com/denoland/rusty_v8.git "${v8_src}"

And build again:

$ V8_FROM_SOURCE=1 cargo build --target x86_64-unknown-linux-musl --release -vv

This time it works. Notice that there were many additional dependencies necessary to get this to build, but it does work.

[devsnek]

The icudtl.dat issue will be fixed when we merge v8 13.0, but that is blocked on another issue not yet fixed in upstream.

[yilong-wang]

I have been trying to get x86_64-unknown-linux-musl target work for deno on an EC2 instance running Ubuntu 24.04. So far, the biggest progress I have made is that build succeeds until the final step which is building deno itself. Sharing my progress here.

1. First, follow https://docs.deno.com/runtime/contributing/building_from_source to set up everything. We might need to export PATH=$PATH:$HOME/.cargo/bin after installing Rust.
2. Change directory into the deno package folder (cd deno). The build should succeed if we run cargo build -vv.
3. Then run V8_FROM_SOURCE=1 cargo build -vv to build both deno and rusty_v8 from the source code. The build might fail because of below error.

ninja: error: '../../../../../.cargo/registry/src/index.crates.io-6f17d22bba15001f/v8-0.106.0/third_party/icu/common/icudtl.dat', 
needed by 'icudtl.dat', missing and no known rule to make it

4. Run below command to fix it.

cd .. && git clone --recurse-submodules https://github.com/denoland/rusty_v8.git
sudo rm -r ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/v8-0.106.0/
mv rusty_v8/ ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/v8-0.106.0/

5. Now cd deno and then V8_FROM_SOURCE=1 cargo build -vv should succeed.
6. Replace crate-type = ["cdylib"] with crate-type = ["staticlib"] in all Cargo.toml files, otherwise static linking will complain. There are two files for me.

vim tests/ffi/Cargo.toml
vim tests/napi/Cargo.toml

7. Install musl-gcc and related dependencies.

apt install musl-tools musl-dev

8. Install targets via rustup.

rustup target add x86_64-unknown-linux-musl

9. Then run below commands to statically compile the target. This is the final step that fails.

# These Linux headers are needed by deno or rusty_v8 but musl doesn't provide them.
ln -s /usr/include/linux /usr/include/x86_64-linux-musl/
ln -s /usr/include/asm-generic /usr/include/x86_64-linux-musl/
ln -s /usr/include/x86_64-linux-gnu/asm /usr/include/x86_64-linux-musl/

# The libc library provided by musl misses some dependencies used by rusty_v8. There seems no simple way to fix it.
# An example error is: <truncated>/index.crates.io-6f17d22bba15001f/v8-0.106.0/v8/src/inspector/string-16.cc:111:(.text+0x2a2): undefined reference to `__isoc23_strtoll'.
# Tried `ln -sf /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-musl/libc.so` but it broke other stuff.

# Needed for fixing "Cross compiling with snapshot is not supported" error.
export DENO_SKIP_CROSS_BUILD_CHECK=1

export CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=musl-gcc
export CC=musl-gcc
export V8_FROM_SOURCE=1
cargo build --target=x86_64-unknown-linux-musl

The libc library provided by musl misses some dependencies used by rusty_v8. There seems no simple way to fix it.

I can mostly confirm that this is the reason why statically compiling x86_64-unknown-linux-musl doesn't work. I was able to fix the Linux header issue by creating symlinks, but I don't know how to fix the libc issue. There might be a lot of work to do in deno or rusty_v8 to get everything work with musl.

BTW I didn't try the approach in https://gist.github.com/kesor/68df53a5d76784a235ca6b0e7efed4d9 because that doesn't seem to work for the latest rusty_v8. It also looks complex and I don't want to do a lot of hacks in the source code which will become very difficult to maintain.