Version `0.4.19` breaks build for target `thumbv4t-none-eabi` about log HOT 9 CLOSED

@guncha I think log is doing the right thing now by not concerning itself with that level of platform specific behaviour. It follows what the target_has_atomic config tells it.

It seems like there might be ongoing work in Rust to enable atomics for RISCV but I’m not across it myself. Maybe rust-lang/rust#98333 is relevant?

from log.

Thanks for the report @Anders429. It’s possible this is just a bug after I needed to apply my clumsy git-fu to split our release into two. I’ll check it out.

from log.

I do think you should probably use the racy versions of those functions, it is possible the allow-list in the old build script might have been missing this target. If this was actually intentional then we should at least call it out in our release notes.

from log.

Looks like the old build.rs file previously explicitly listed this target in the target_has_atomics() function. This was originally added in #488.

I'm not entirely sure on the atomic story for this target. Should thumbv4t-none-eabi not have been included in this list originally? The target spec does seem to indicate it should have some atomic support, but I don't know to how that fits in with the atomic support needed for log. I'm certainly not an expert on this by any means.

I'm definitely fine with just using the racy versions if that's the actual proper thing to do going forward.

from log.

Ok, it looks like this was intentional, and we were incorrectly enabling the atomic versions on thumbv4t-none-eabi, and probably others too. Our old build script was just thoroughly insufficient for target detection. Sorry about the mixup @Anders429! I'll update the release notes to call this out.

from log.

I've updated our release notes and will leave this issue open for a while for others using affected targets.

from log.

Great, thanks for the quick response!

from log.

Same issue with riscv32imc-unknown-none-elf. The target doesn't have atomic instructions, but according to the RISC-V spec for RV32I:

naturally aligned loads and stores are guaranteed to execute atomically

Which should be enough to safely update the max log level, no?

from log.

This issue has been open for a few months and we've just queued up an 0.4.20 release, so I think it's a reasonable to point to close this one now. Thanks everyone for all the input!

from log.