Closed KernelPanic0 closed 2 months ago
We should add a patch which drops that stdio.h code. It's totally dead, so I guess the compilers we test on filter it out early enough that it doesn't cause problems, but it shouldn't be there.
I'll PR to delete that code, and backport to 0.10.0 which should hopefully fix your issue.
Having said that, the problem is in your copy of stdio.h so I feel I should say "not our fault" :).
Having said that, the problem is in your copy of stdio.h so I feel I should say "not our fault" :).
I agree. Most of our build issues are either bug in cc
or wrong C compiler and I'd rather not pollute our code with special exceptions to fix these. (I believe there's a way to print a message "please check your compiler before filing an issue" on build failure.)
That being said, if we can easily delete dead code and it's likely to improve reliability on multiple targets then I don't object to it.
@Kixunil in this case we are already trying to eliminate all calls into the C standard library because they don't need them and they break wasm (at runtime).
So deleting this code is totally within the normal goals of this crate ... it's just that fixing this particular bug is not something we'd be willing to take too many pains to fix. (But fortunately it turns out to be zero marginal pain because we want to delete the code anyway.)
I am trying to cross compile a rust application from Ubuntu to a Windows machine. With podman installed, I run the following:
cross build --release --target x86_64-pc-windows-msvc
Everything is fine, up until the compiler reaches the secp256k1-sys crate.Am I missing something obivous?