musl upstream is down

[udoprog]

Seems like https://git.musl-libc.org/git/musl is down (504 Bad Gateway), meaning building this project from git no longer works.

I'm not sure how to contact the musl project, so I'm opening an issue here for now since this is the project which breaks for me.

It might be an idea to host a mirror of the project on GitHub with the commit being depended on.

[tgross35]

Musl uses a mailing list, the address is on https://musl.libc.org/support.html and archives are at https://www.openwall.com/lists/musl/. There is also a mirror at https://github.com/bminor/musl but I'm not sure that is any more reliable.

To be certain, you were working on testing libm and not just using it right? Musl shouldn't be needed otherwise. You should also be able to remove the musl requirement by disabling the build-musl feature.

[udoprog]

I was just depending on compiler_builtins from git in some project with features = ["mem"]. Even if I wasn't using musl I believe it's being checked out defensively by cargo since it's a submodule. The build failure was just related to trying to check it out and failing. You can see it here (until Github removes the log):

https://github.com/udoprog/musli/actions/runs/13504803567/job/37731811742

Note that I switched to using the crates.io version of compiler_builtins since it seems to have everything I was using before.

[tgross35]

Thanks for the link. That is interesting; libm is a submodule of compiler-builtins so that makes sense, but I wouldn't expect it to pull all submodules recursively. I'm hoping to merge libm into compiler-builtins sometime in the near future, maybe that will also make the problem go away.

Out of curiosity, why do you need compiler_builtins as a direct dependency? It would be nice if we could eventually improve/fix any remaining usecases so this is no longer ever needed.

[udoprog]

Oh, good question.

If memory serves there used to be a missing symbol during linking. That no longer seems to be the case. So I've removed the dependency now.

Thanks for the poke!

[tgross35]

That's great! If you do run into problems like that in the future, open an issue in compiler-builtins (or rust-lang/rust) and we'll try to squash it.

[michael-p]

I'm running into the same issue - I have a fork of libm that is used as a git dependency in one of my projects. Now this sometimes fails in CI because Cargo fetches my libm fork repository and that includes musl as a submodule:

[...]
Updating git repository `[https://github.com/michael-p/libm.git`](https://github.com/michael-p/libm.git%60)
    Updating git submodule `[https://git.musl-libc.org/git/musl`](https://git.musl-libc.org/git/musl%60)
warning: spurious network error (3 tries remaining): unexpected http status code: 504; class=Http (34)
warning: spurious network error (2 tries remaining): unexpected http status code: 504; class=Http (34)
warning: spurious network error (1 tries remaining): unexpected http status code: 504; class=Http (34)
error: failed to load source for dependency `libm`

Caused by:
  Unable to update https://github.com/michael-p/libm.git?branch=master#69219c49

Caused by:
  failed to update submodule `musl`

Caused by:
  failed to fetch submodule `musl` from https://git.musl-libc.org/git/musl

Caused by:
  network failure seems to have happened
  if a proxy or similar is necessary `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  unexpected http status code: 504; class=Http ([34](https://github.com/michael-p/smartcam/actions/runs/13607561157/job/38042360093#step:4:35))

You should also be able to remove the musl requirement by disabling the build-musl feature.

@tgross35 Could you elaborate on how that works? libm at least does not declare a build-musl feature in its Cargo.toml, and even if it did I guess Cargo would still try to checkout the musl submodule?

[udoprog]

@michael-p I believe the idea is that it works without depending on compiler-builtins at all, through the Rust compiler. So just try and remove the dependency and see if it works.

[michael-p]

@michael-p I believe the idea is that it works without depending on compiler-builtins at all, through the Rust compiler. So just try and remove the dependency and see if it works.

@udoprog I do not depend on compiler-builtins, but just on the libm crate (well, a fork of it, to be precise). I cannot remove that dependency because otherwise math functions like sin, cos etc do not work in a no_std environment. The custom fork is needed because of some super ugly but useful hacks that sadly have zero chance of being upstreamed :)