Remove manual libatomic reference

[link2xt]

Reverts revert of 32a303a from ddd0478

Fixes #2043

[sfackler]

The build is red.

[link2xt]

It fails for arm-unknown-linux-gnueabihf-openssl-vendored-true and arm-unknown-linux-gnueabihf-openssl-vendored-false.

[sfackler]

Those are the builds that are failing, yes.

[BlackDex]

@sfackler I don't know about Android, but the Linux builds should work just fine with changing dylib to static i think.
Also, for that exact same system i need to use RUSTFLAGS: "-Clink-args=-latomic" else building on that platform fails for anything that uses OpenSSL (v1.1.1 or v3.x.x).
See:
https://github.com/BlackDex/rust-musl/blob/fe53e9361b6f9e0d9efd578f606dcad0dffd9730/.github/workflows/rust-musl.yml#L265C36-L268

And:
https://github.com/dani-garcia/vaultwarden/blob/f863ffb89a0f2a0a682c67110af32c731b5b9fcb/docker/Dockerfile.alpine#L70-L71

What i find a bit strange is that the check is done to see if it is static, and then the atomic lib is added dynamic.
That will always break builds which try to build statically compiled binaries, since now that is a dynamically linked library.

One compromise would be to either say, if kind is static use static, and else use dylib.
Because of this bug/regression i'm currently forced to pin the crates to a version before this, and people are having issues now trying to build Vaultwarden on FreeBSD for example.

What would be the best way to go to have this solved?

[sfackler]

Yeah, I think it makes sense to statically link to libatomic in these contexts. I'm not totally sure why we're dynamically linking currently.

[BlackDex]

Ill test what happens if i convert it to static and use a newer version and report back.

[BlackDex]

@sfackler, if i change it to:

println!("cargo:rustc-link-lib=atomic");

Then it works just fine for me on both gnueabi and musleabi.

[link2xt]

Let's close it favor of #2094