Marshal.Closures vs native OCaml DLL #7839
Comments
|
Comment author: @stedolan Are you describing a situation where code written in OCaml is compiled as non-PIC, but the runtime system is placed in a DLL? If so, I'm surprised that's even possible. |
|
Comment author: @db4 Why not? Under Windows (my case) you don't have PIC at all, under Linux/x86 PIC is not required for DLLs, just recommended. Only Linux/x64 prohibits to link non-PIC code into a DLL. |
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 7839
Reporter: @db4
Status: new
Resolution: open
Priority: normal
Severity: minor
Platform: x86
OS: Windows
Version: 4.07.0
Category: runtime system and C interface
Monitored by: @nojb @gasche
Bug description
I thought it should always be possible to marshal/unmarshal closures from/to the same OCaml program (with Marshal.Closures flag). Unfortunately, if OCaml system is placed into a DLL that is loaded into a main exe written in another language, this becomes problematic. Non-PIC OCaml code contains relocations that will be resolved to different addresses depending on the DLL base address (assigned by OS DLL loader). Then code fragment digests will also be different and Marshal.from_* functions will fail.
I realize this is quite rare case (most people nowadays use x64 PIC code that is not affected) but IMHO it should be at least documented (if not fixed).
The text was updated successfully, but these errors were encountered: