BB_C

Oh, we got a nu-M$er here. lol.

Along the same vein, too many open source projects don’t factor in non-“gnu/linux” environments from the start.

No one is entitled to anything from open-source projects.

I spent time making sure one of my public tools was cross platform once. This was pre-Rust (a C project), and before CI runners were commonly available.

I did manage it with relative ease, but Mac/mac (what is it now?) without hardware or VMware wasn't fun (or even supported/allowed). Windows was a space hog and it's a shit non-POSIX OS created by shits anyway, and Cygwin/MSYS wouldn't have cut it for multiple reasons including performance. The three major BSDs, however, were very easy (I had prior experience with FreeBSD, but it would have been easy in any case).

People seem to have forgotten that doing open-source was supposed to be fun first and for most. Or rather, the new generation seems to never have gotten that memo.

POSIX is usually where a good balance between fun and public service is struck. Whether Mac/mac is included depends on the project, AND the developers involved. With CLI tools, supporting Mac/mac is often easy, especially nowadays with CI runners. With GUIs, it's more complicated/situational.

Windows support should always be seen as charity, not an obligation, for all projects where it's not the primary target platform.

You need to call ./y.sh prepare again

Aha! Good to know. And yes, improved documents would be of great help.

Thanks again for working on this.

But running

./y.sh prepare
./y.sh test --release

does work. That's what gave me the impression that clean all doesn't actually clean everything!

Yeah, apologies for not communicating the issue clearly.

cp config.example.toml config.toml
./y.sh prepare
./y.sh build --sysroot
./y.sh clean all
# above commands finish with success
# below, building succeeds, but it later fails with "error: failed to load source for dependency `rustc-std-workspace-alloc`
./y.sh test --release 

And then trying to use the "release" build fails:

% CHANNEL="release"  ./y.sh cargo build  --manifest-path tests/hello-world/Cargo.toml
[BUILD] build system
    Finished `release` profile [optimized] target(s) in 0.03s
Using `/tmp/rust/rustc_codegen_gcc/build/libgccjit/d6f5a708104a98199ac0f01a3b6b279a0f7c66d3` as path for libgccjit
   Compiling mylib v0.1.0 (/tmp/rust/rustc_codegen_gcc/tests/hello-world/mylib)
error[E0463]: can't find crate for `std`
  |
  = note: the `x86_64-unknown-linux-gnu` target may not be installed
  = help: consider downloading the target with `rustup target add x86_64-unknown-linux-gnu`
  = help: consider building the standard library from source with `cargo build -Zbuild-std`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `mylib` (lib) due to 1 previous error

I will make sure to report issues directly in the future, although from account(s) not connected to this username.

Oh, and clean all doesn't work reliably. Since trying to build in release mode after building in debug mode then cleaning is weirdly broken.

And It's not clear from the README how to build in release mode without running test --release. And the fact that all combinations of --release-sysroot and --release --sysroot and --release --release-sysroot exist doesn't help 😉

@antoyo@programming.dev

I gave this a try for the first time. Non-LTO build worked. But LTO build failed:

x86_64-pc-linux-gnu-gcc-15.0.0: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found

I don't have the time to build gcc and test. But presumably, liblto_plugin.so should be included with libgccjit.so?

Great to see this progressing still.
Great to see you posting here as well.
All the best.

perfect 80/20.
as in, 80% fully agree, 20% what a retard.

Where does one even start ?

In any rust project, you start with API docs, and the examples folder if one exists. Just make sure the examples belong to the current version you will depend on, not the master/main branch. The link above is from v0.13.1 for example.

Didn't click on your links. But LEA does this move against any network that may offer anonymization. Don't use Tor hidden services. Don't go near I2P. Stay away from Freenet...etc. This even includes any platform that is seen as not fully under control, like Telegram at some point.

In its essence, this move is no different from "Don't go near Lemmy because it's a Putin-supporting communist platform filled with evil state agents".

Does any network that may offer anonymization (even if misleadingly) attract undesirable people, possibly including flat out criminals? Yes.

Should everyone stay away from all of them because of that? That's up to each individual to decide, preferably after seeing for themselves.

But parroting "think of the children" talking points against individual networks points to either intellectual deficiency, high susceptibility to consent-manufacturing propaganda, or some less innocent explanations.

Apologies if I was presumptions and/or my tone was too aggressive.

Quibbling at No Moderation = Bad usually refers to central moderation where "someone" decides for others what they can and can't see without them having any say in the matter.

Bad moderation is an experienced problem at a much larger scale. It in fact was one of the reasons why this very place even exists. And it was one of the reasons why "transparent moderation" was one of the celebrated features of Lemmy with its public Modlog, although "some" quickly started to dislike that and try to work around it, because power corrupts, and the modern power seeker knows how to moral grandstand while power grabbing.

All trust systems give the user the power, by either letting him/her be the sole moderator, or by letting him/her choose moderators (other users) and how much each one of them is trusted and how much weight their judgment carries, or by letting him/her configure more elaborate systems like WoT the way he/she likes.