Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support wasm32 Build Targets #72

Open
au-z opened this issue Sep 21, 2024 · 2 comments
Open

Support wasm32 Build Targets #72

au-z opened this issue Sep 21, 2024 · 2 comments

Comments

@au-z
Copy link

au-z commented Sep 21, 2024

Hey there, cool project! I am interested in using vdb-rs to create a WASM loader for NanoVDB and learning Rust and VDB in more depth along the way. 👍
When trying to build vdb-rs for wasm32, I see the following issue(s):

$ cargo check --target wasm32-unknown-unknown
...
error[E0277]: the trait bound `u64: bitvec::store::BitStore` is not satisfied
   --> src/reader.rs:560:25
    |
560 |                         value_mask.as_bitslice(),
    |                         ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `bitvec::store::BitStore` is not implemented for `u64`
    |
    = help: the following other types implement trait `bitvec::store::BitStore`:
              u16
              u32
              u8
              usize
note: required by a bound in `bitvec::slice::BitSlice`

I believe this is due to some Rust attributes in bitvec which conditionally compile u64 code based on the target:
https://github.com/ferrilab/bitvec/blob/main/src/store.rs#L194

#[cfg(target_pointer_width = "64")]
store!(u64 => BitSafeU64);

I found an identical issue laid out here but wondering if there are other options for resolving this rather than tearing out bitvec, which seems aggressive. With the WASM Memory64 proposal still nascent, maybe there is something else we can do to target wasm32 in the meantime?

@Jasper-Bekkers
Copy link
Member

I think this should be fixed by making bitvec work on 32 bit CPUs, since it also seems to be holding back other projects. Maybe they can live with something slightly less optimal for the sake of compatibility?

I'm not super interested in removing bitvec from this crate since I expect it to be a relatively sizable change.

@Jasper-Bekkers
Copy link
Member

If there is a way you can see this be done easily and are willing to provide fixes for them, I'm happy to review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants