Unable to find crate proc_macro on musl target
#40174
Comments
|
Yes this is currently intentional. The proc_macro crate is only a dynamic library which the musl target currently doesn't support. I unfortunately don't think this will be easy to fix... |
|
I understand why the proc macro crates need to be dynamic: they are loaded and run dynamically by the compiler. However what I don't understand is why the |
|
Is there some technical hurdle that makes it hard to do, or is it just not done because it's such a minor case? |
|
The simplest test for this seems to be:
build with (succeeds): and with (fails): When |
|
Okay, I did some testing. I After that, I built a After that, I copied the build artefacts from After that, I try to compile the things that failed before with musl target → it works. So, it seems that there isn't any real technical hurdles. (or if there is, I haven't encountered them yet) @alexcrichton, what do you think of distributing |
|
Btw. I did this work on a Linux host. Tried to do the same on macOS (with musl target of course), but on macOS the linking fails with |
|
Ah, okay, the |
|
Yes there are technical hurdles in terms of build system of doing that. This is also rarely what you want because there's no reason to have a full Rust parser linked into a binary (when it's not used). |
|
I see, that's a convincing argument. |
|
Hello,
|
Musl target does not work with proc-macro. See rust-lang/rust#40174 Removing serde-derive allows building tectonic for musl targets.
|
Hello! I've got this issue, as well -- deps relying on I'm currently compiling rustc for my target and it seems easiest to create |
|
For those following various links to this issue, it is important to note that you can compile code using
|
|
Reopening as this seems to still be a significant issue for people building from musl systems |
jonas-schievink
added
A-linkage
|
Many important crates like OpenSSL need to be vendored and cross-compiled to musl (e.g., sfackler/rust-openssl#980 (comment)), but when I tried to do that, complications like feature flags not working with workspaces (e.g, rust-lang/cargo#5015) started cropping up, and I threw up my hands and gave up on musl. Even if there aren't plans to work on it in the near term, I don't think this issue should be considered fixed until either (1) It is easy to cross-compile apps to musl or (2) it is possible to cis-compile proc_macro targets on musl. |
jonas-schievink
added
the
T-compiler
Use starlark to de-duplicate most of the configuration. Use rust:buster-slim base as there is a problem with rust on alpine currently: rust-lang/rust#40174 Signed-off-by: Joe Groocock <[email protected]>
|
There are likely much better solutions, but… I've just come across https://github.com/dtolnay/watt ; and… would integrating this into rustc as a secondary backend for use only on platforms where regular proc macros aren't supported be a solution? It wouldn't support all the use cases I think, due to regular proc macros being allowed to eg. interact with the FS, but it should already support a number of use cases. And maybe, with time, the API could be extended so that proc macros could all be compiled with wasm, and the current dylib approach could be dropped, thus making porting rustc to a new architecture a lot easier? |
|
@mati865 I'm not sure, I've pinged here following a message from IRC that said this happened just today -- don't know for sure the version of the compiler used, so I've just pinged them |
|
@mati865 If it's part of the brand new Rust 1.43, then yes, it is still an issue. On Alpine, the heavily patched rust package (1.39) can compile without any trouble. However, on the very same machine, any version of Rust (including 1.39 and 1.43) installed via rustup (and therefore without those patches) is subject to this issue. |
|
@breard-r Rust 1.43 don't include this patch and you can try 1.44 beta from rustup. |
|
@12101111 Thank you! I've just installed 1.44.0-beta via rustup and it builds! 😃 |
|
Great! Closing as fixed then. |
|
This is still broken for me using Full linker arguments |
It seems you don't install musl-dev |
|
That fixed it, thank you! |
either the opentelemetry or rayon requires that the `musl-dev` package is installed while building otherwise the build will fail with the following error message: `.../bin/ld: cannot find crti.o: No such file or directory` ref: rust-lang/rust#40174 (comment)
|
If you're bumping into this in 2021, it's likely that you need to run |
…command" This reverts commit ff9a378. Reasons for reverting: 1. Compiling via musl is necessary to statically link dependencies and create a truly standalone Rust binary. [1] 2. Alpine-based Rust images are required for the build stage because such systems support dynamic linking, which is also needed for statically-linked binaries. [2] 3. Determining the target architecture and templating the correct value for the --target flag is necessary for the statically-linked binary to be built correctly. [2] [1]: https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#linux [2]: rust-lang/rust#40174 (comment)
* add compose.yaml * add Dockerfile * update README * Dockerfile: uncomment CMD instruction * add .dockerignore * Dockerfile: use scratch image for second stage * Dockerfile: use newer OpenSSL version (3.0.9) * Dockerfile: use Alpine-based Rust image to skip building OpenSSL * Dockerfile: expose to localhost only by default * Dockerfile: allow building for different architectures (AMD64 and ARM64) Dockerfile now detects the architecture being used during the build process and templates in the correct Rust target architecture * compose.yaml: include command line * compose.yaml: listen on 127.0.0.1 only * compose.yaml: remove healthcheck due to using scratch image * README.md: restore old table format * rename compose.yaml to docker-compose.yml * docker-compose.yml: include version line * update .dockerignore * README.md: update Docker instructions to expose only on localhost * add workflow to build and push container images to quay.io * docker-compose.yml: harden configuration * docker workflow: add paths-ignore section * Dockerfile: let Rustup handle architecture detection More flexible as the build process will now automatically adapt to whatever architecture the container is being built on, without needing to explicitly list out each supported architecture * Docker: further security hardening - Run as a non-privileged user within the scratch container - Add security_opt: - no-new-privileges:true to docker-compose.yml * Dockerfile: Switch to Debian-based images and simplify build command - rust:1.80-alpine replaced with rust:1.80 for the builder stage - alpine:3.20 replaced with debian:12.6-slim for the user-stage - Build command simplified to use default target architecture * Cargo.toml: correct note on optimisations * docker-compose.yml: use quay.io image by default * rename docker-compose.yml to docker-compose.yaml * compose: build image from local repo by default * Revert "Dockerfile: Switch to Debian-based images and simplify build command" This reverts commit ff9a378. Reasons for reverting: 1. Compiling via musl is necessary to statically link dependencies and create a truly standalone Rust binary. [1] 2. Alpine-based Rust images are required for the build stage because such systems support dynamic linking, which is also needed for statically-linked binaries. [2] 3. Determining the target architecture and templating the correct value for the --target flag is necessary for the statically-linked binary to be built correctly. [2] [1]: https://doc.rust-lang.org/1.13.0/book/advanced-linking.html#linux [2]: rust-lang/rust#40174 (comment)
Using procedural derive macros on musl seems to work just fine for the most of the cases, but there is one pitfall; in some cases like this dtolnay/proc-macro-hack#6 build fails because not only the crate that implements the macro (crate marked with
proc-macro = true), but also another, normal crate links to theproc_macrocrate. "Normal" crates are unable to findproc_macrowhen built on musl target:The text was updated successfully, but these errors were encountered: