Compiling fails on FreeBSD when the websocket-rustls feature is enabled

[yonas]

Compiling fails on FreeBSD when the websocket-rustls feature is enabled

[rapiz1]

rustc 1.76.0-nightly (37b2813a7 2023-11-24) (built from a source tarball)

I can build using rustc 1.76.0 (07dca489a 2024-02-04) without issues. You may want to update to the latest stable or nightly.

It's meant to break nightly as per dalek-cryptography/curve25519-dalek#619 (comment) I agree the their argument as well: no point of supporting out of date nightly

[rapiz1]

it looks pretty like a dependency issue. could you please try the latest rust toolchain and compile after a cargo update? cc @sunmy2019

I honestly have no idea why this is happening given we have tested it on ubuntu

name: Run tests with rustls
        run: cargo test --verbose --no-default-features --features server,client,rustls,noise,websocket-rustls,hot-reload

there's a great chance it's a packaging thing.

[yonas]

could you please try the latest rust toolchain and compile after a cargo update?

@rapiz1 Thanks, I'm getting the same error after running cargo update.

[rapiz1]

Would you mind also sharing your rustc version? @yonas

[sunmy2019]

Enabling rustls requiring disabling default features. Can you try this?

cargo build --release  --no-default-features --features websocket-rustls

[sunmy2019]

See similar situations in jdx/mise#1630

[yonas]

Would you mind also sharing your rustc version?

rustc 1.76.0-nightly (37b2813a7 2023-11-24) (built from a source tarball)

Can you try cargo build --release --no-default-features --features websocket-rustls

I'm getting the same errors.

[sunmy2019]

rustc 1.76.0-nightly (37b2813a7 2023-11-24) (built from a source tarball)

One of our dependencies only supports the latest nightly. Others have filed report here: dalek-cryptography/curve25519-dalek#619

Use something other than nightly will be good.

[yonas]

Upgrading to nightly on linux fixed the issue.

FreeBSD ports doesn't yet have the latest nightly, so I've resorted to pinning curve25519-dalek to v4.1.1.

Use something other than nightly will be good.

I agree, it should be optional. For example, I wonder if rathole's build.rs / Cargo.toml could detect if nightly is being used and then switch the version of curve25519-dalek from =v4.1.1 to >=v4.1.2.

[rapiz1]

Glad to hear that it worked for you. That is possible but we will not introduce the maintenance burden for an outdated nightly build. Whenever FreeBSD gets to the latest nightly or stable of rustc, it will work seamlessly. The build should never fail on stable toolchain. Once you opt in for nightly, you're mostly responsible for resolving dependencies on your own because there's no compatibility promise for nightly. I will strongly suggest you use stable toolchain to compile rathole, if you don't have special needs.