windows support #31
windows support #31
Conversation
| #[cfg_attr(windows, repr(i32))] | ||
| #[cfg_attr(not(windows), repr(u32))] |
There was a problem hiding this comment.
Maybe we should instead switch to repr(C)? Based on this in the reference: https://doc.rust-lang.org/reference/type-layout.html#reprc-field-less-enums
It sounds like we should maybe abandon this approach in the long term since it risks invoking UB and isn't scalable to particularly weird target/compiler configs.
There was a problem hiding this comment.
Using repr(C) fails with the same issue unfortunately
| @@ -0,0 +1,2 @@ | |||
| [target.x86_64-pc-windows-msvc] | |||
| rustflags = ["-C", "link-arg=/STACK:8388608"] | |||
There was a problem hiding this comment.
I'm not sure what to do about this either, it's required in a project that uses swiftnav-rs and here as well, apparently this is by design for how rust links with native libraries:
https://doc.rust-lang.org/beta/unstable-book/language-features/link-args.html
There was a problem hiding this comment.
Is is something in our code that requires the 8 MB stack size specifically?
There was a problem hiding this comment.
It would be nice to understand this change more, but during compilation things will crash with a thread 'main' has overflowed its stack error otherwise-- I think 4MiB worked, 8MiB was a "just in case" value.
LSN on windows uses the stack by default for allocation-- but this is a runtime thing-- I don't think it would causes issues until something was actually invoked. Nevertheless I tried to enable heap allocation with some compiler flags and it didn't seem to affect this issue.
This made me think it might be a huge table somewhere that gets initialize as part of setting up globals, like the geoid grid... I tried disabling the compilation of the geoid grid but that didn't help.
Didn't try anything else past this though.
There was a problem hiding this comment.
You're probably right. I'm cool if this is a workaround, maybe we can investigate it later.
There was a problem hiding this comment.
Ok, this is definitely a workaround for now, at some point we can (hopefully) revisit and see if we can track down what's requiring such a large stack
Fixes a compilation issue on Windows and adds a stack size linker flag which is necessary to run the tests (sadly, this flag is also needed if you are linking against
swiftnav-rson windows).