Add x86_64-unknown-linux-musl library release

[cd-work]

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 #49.

---

There have been several comments in related issues about how to build rusty_v8 and deno on musl, many of which are outdated and do not work anymore. Hopefully getting this upstreamed can work around having to hunt down the correct solution for building things (see #49 and denoland/deno#3711).

I'm mostly creating this PR to gauge if the approach taken here is something that can be upstreamed. It still requires rust-lang/docker-rust#104 and a patch to chromium_build to work:

diff --git a/config/compiler/BUILD.gn b/config/compiler/BUILD.gn
index 211684cd2..9e27e958f 100644
--- a/config/compiler/BUILD.gn
+++ b/config/compiler/BUILD.gn
@@ -1553,7 +1553,6 @@ config("default_warnings") {
         # TODO(https://crbug.com/1316298): Re-enable once test failure is figured out
         cflags += [
           "-Xclang",
-          "-no-opaque-pointers",
         ]
       }

As far as I can tell, there are currently no other targets built in a Docker container and the maximum runtime of existing toolchains seems to be about 30 minutes. Based on my tests (https://github.com/phylum-dev/cli/runs/6716629634?check_suite_focus=true), this build would take around 2 hours on GitHub's runners.

I'd assume you're generally interested in providing musl builds? If you have any suggestions, please let me know.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[littledivy]

Thanks for the PR! Yes, we are interested in MUSL builds.

As far as I can tell, there are currently no other targets built in a Docker container and the maximum runtime of existing toolchains seems to be about 30 minutes. Based on my tests (https://github.com/phylum-dev/cli/runs/6716629634?check_suite_focus=true), this build would take around 2 hours on GitHub's runners.

We used to compile for aarch64-linux-android in Docker using cross (Temporarily removed because it blocked a V8 upgrade). The CI was around ~30mins with sccache. See https://github.com/denoland/rusty_v8/blob/main/Dockerfile

[cd-work]

It seems like the main chromium_build upstream branch is not actually the working branch for deno's chromium_build fork. So I'm not quite sure what the expected way of updating the project is since there haven't been a lot of PRs and issues either.

The branch 20220524 is currently used and seems to be based upon upstream and up-to-date, so I've decided to send a PR to remove the flags there: denoland/chromium_build#197

[cd-work]

It seems like maintenance of chromium_build is somewhat lacking, considering I've opened the PR over a month ago with zero feedback.

Is that project not something that is actively maintained? If so, should patches be applied/upstreamed in a different manner?

I'd appreciate some feedback in any direction, after a month of waiting I'm just not certain if this is an issue with my process, or if maintenance is just taking some time to get around to the open issues.

[louislang]

Are there any updates on this PR? It be super helpful to have this upstream.

[bartlomieju]

@piscisaureus please take a look

[ry]

Closing because it's very old. Please open a new PR if you want to continue this.

[cd-work]

I am not going to open a new PR, considering the only reason I can see for this not being resolved is due to the missing response from a maintainer and I don't see that changing with a new PR.

However I do want to make it very clear that I still have interest in an x86_64-unknown-linux-musl release. If a maintainer ever wanted to get this to work, it shouldn't require my input since it's a pretty trivial patch, but please do reach out if you have any questions.