compiling for 32-bit arm targets about bitvec HOT 7 CLOSED

Thanks for the quick reply and explanation of the fix, makes sense.

Unfortunately, I can't seem to override bitvec's version of radium with your patched one, since the former pins to 0.2 and the latter is at 0.3.
Cargo gives me:

warning: unused manifest key: patch.crates-io.radium.commit
warning: Patch `radium v0.3.0 (https://github.com/myrrlyn/radium.git#f37e5698)` was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.
   Compiling radium v0.2.0

Re: targets you don't have --- I'd be more than happy to buy you a few boards and programmers if you ever want to play around with stm32 microcontrollers.
The stm32f1-based "blue pill" and "black pill" chinesium breakout boards became popular a few years back as an atmega/arduino alternative and stm sells official "nucleo" dev boards for pretty much their entire stm32 line.
Just email me ([email protected]) a shipping address and any particular boards you want to check out.

from bitvec.

Hi @myrrlyn Just wanted to follow up and confirm that everything is working properly on my ARM-based microcontroller. Thanks again for the great library!

from bitvec.

So it turns out that the standard library conditionally manifests the atomic types based on the target_has_atomic test, which is not available on stable for libraries to use: https://github.com/rust-lang/rust/blob/a06baa56b95674fc626b3c3fd680d6a65357fe60/src/libcore/sync/atomic.rs#L2094-L2129

Since radium is developed and tested on x86_64, and not on other targets, we just didn't think to check the gates on these types. I've submitted a patch to radium that gates the use of Atomic*64 on target_pointer_width, as that is the closest proxy we have for detecting whether a target has atomically-available 64-bit regions. If it is accepted and published, I will update bitvec to use it.

For now, use this override in your project manifest:

# Cargo.toml

[patch.crates-io]
radium = { git = "https://github.com/myrrlyn/radium.git", commit = "f37e569" }

This ought to pull my patch of radium, which compiles and passes tests on i686-unknown-linux-gnu and compiles on thumbv7m-none-eabi. If you have any further issues relating to absent symbols with any part of the bitvec dependency tree, feel free to note them in this issue. It is a bug in bitvec as a project to fail to compile on any 32-bit or 64-bit target. I do not currently make any guarantees about performance on targets I do not personally have, but I will happily add them as needed.

from bitvec.

This is what I get for doing minimal-effort support work over Christmas, I guess.

When radium v0.3 is published to crates.io, I will issue an immediate patch release of bitvec (0.16.2).

from bitvec.

No worries, hope you had a great holiday.
I'm thrilled that you wrote such a nice library for everyone to use.

Once the bitvec patch release is up (on crates.io or github) I'll test compilation and close this issue.

from bitvec.

Commit 253143e (not currently on a tracked branch) is published to crates.io. I will incorporate it into trunk later.

from bitvec.

I'm experiencing a regression on this bug when using version 0.19.0 or later with the target thumbv4t-none-eabi. Can you rule out the possibility that the target triple is at fault here?

from bitvec.