C shim for static context to address Windows MinGW64 runtime failure #10
Conversation
… failure This change attempts to address a Windows MinGW64 runtime failure that occurs during testing, where we see a "32 bit pseudo relocation out of range" error. The error suggests an issue with how GHC handles pointers in Windows executables. 1. Adds a C shim (hs_secp256k1_shim.c) to handle the static context 2. Updates the Haskell FFI bindings to use the shim instead of direct access 3. Bumps version to 0.3.1 to reflect the FFI interface change
|
resolves #6 |
|
ping @ProofOfKeags |
|
I don't know what's wrong the CI builds |
|
So I assume your limitation in haskell is that you can't reference global variables, so you needed to make a getter function to return the pointer to the global structure? The structure should be stored and mapped in the BSS segment of the process when the library is loaded, and externally referenced (via the pointer variable you're using). That means it's accessable to the linker (or |
|
On Linux, Haskell FFI sometimes works with global C variables indirectly because the ELF linker and GHC's runtime can resolve symbols like dlsym, even for globals — though Haskell itself doesn't support foreign import variable. If everything is statically linked, it just works. On Windows (MinGW), global variables in DLLs are not exported by default unless marked with __declspec(dllexport), and Haskell can't import global variables directly anyway. Its FFI only supports importing functions. So you must use a getter function that returns a pointer to the global. At least that's my understanding of it, please correct me if I'm wrong. |
|
Yep, you are correct. I just re-read the |
I updated the build process as well, all tests pass. |
This change attempts to address a Windows MinGW64 runtime failure that occurs during testing, where we see a "32 bit pseudo relocation out of range" error. The error suggests an issue with how GHC handles pointers in Windows executables.