-
Notifications
You must be signed in to change notification settings - Fork 320
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
target x86_64-unknown-linux-musl #49
Comments
If anyone is interested, I have compiled DENO with V8 in Alpine Linux Docker container - without https://gist.github.com/kesor/68df53a5d76784a235ca6b0e7efed4d9 Enjoy! |
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. |
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. |
This adds x86_64-unknown-linux-musl as a new supported target for the pre-built rusty_v8 library releases, which should avoid multiple downstream consumers having to build this themselves. This target is useful when trying to build statically-compiled executables, which seems like a good thing to support for the purpose of using deno_core as an embedded JavaScript runtime. Closes denoland#49.
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? |
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 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. |
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. |
I have been trying to get
I can mostly confirm that this is the reason why statically compiling BTW I didn't try the approach in https://gist.github.com/kesor/68df53a5d76784a235ca6b0e7efed4d9 because that doesn't seem to work for the latest |
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.
The text was updated successfully, but these errors were encountered: