Continuous Deployment build fails

[hannobraun]

See https://github.com/hannobraun/Fornjot/actions/runs/1993939647.

This is most likely due to #368. I'll take a look tomorrow.

cc @hendrikmaus

[hendrikmaus]

I'll also take a peek tomorrow. Thanks for mentioning me.

[hendrikmaus]

That error message a new one for me:

error: cannot produce cdylib for `cuboid v0.1.0 (/project/models/cuboid)` as the target `aarch64-unknown-linux-musl` does not support these crate types

According to Cargo's documentation, this should work on all major operating systems:

--crate-type=cdylib, #[crate_type = "cdylib"] - A dynamic system library will be produced. This is used when compiling a dynamic library to be loaded from another language. This output type will create *.so files on Linux, *.dylib files on macOS, and *.dll files on Windows.

Source: https://doc.rust-lang.org/reference/linkage.html

I wonder if it has something to do with GNU vs musl 🤔

(...)

I think that is the culprit, I can compile the GNU targets, but musl refuses to:

$ cargo build --release --target x86_64-unknown-linux-musl
error: cannot produce cdylib for `cuboid v0.1.0 (/home/hmaus/Code/Opensource/Rust/fornjot/repo/models/cuboid)` as the target `x86_64-unknown-linux-musl` does not support these crate types

Now the musl binaries, to me at least, are only a nice to have at this point. So @hannobraun we can drop them and only continue to build GNU targets for Linux.

I opened a pull-request: #370

[hendrikmaus]

There could be a solution though, setting RUSTFLAGS="-C target-feature=-crt-static" rust-lang/cargo#8607 (comment)

But that resulted in a ton of cc linking errors for me.

There is also a section on the topic in Cargo's docs: https://doc.rust-lang.org/reference/linkage.html#static-and-dynamic-c-runtimes

[hannobraun]

Thank you for looking into this, @hendrikmaus!

Now the musl binaries, to me at least, are only a nice to have at this point. So @hannobraun we can drop them and only continue to build GNU targets for Linux.

I agree that they're just a nice-to-have. Dropping them for now is fine, and I think there are two alleviating factors:

1. There are other ways to get binaries that run on most Linux systems, by building against an old glibc, I think. So once that becomes a priority, we'll have options.
2. Building as a dynamic library isn't a long-term solution anyway (Switch model system to WASM #71), so we might be able to re-introduce musl builds later.

There could be a solution though, setting RUSTFLAGS="-C target-feature=-crt-static" rust-lang/cargo#8607 (comment)

But that resulted in a ton of cc linking errors for me.

I think it's probably not worth getting too deep into this. At some point, we'll switch models to WASM, most likely, which will come with a whole separate host of problems and opportunities.