Open
Description
With the minimum requirements for OCaml at Windows 10 (I think), we should consider moving off the legacy msvcrt.lib
.
Here is the branch I have used for testing: https://github.com/jonahbeckford/flexdll/commits/0.43%2Bucrt
There are two blockers:
- Unsupported relocation kind 0003 for __GSHandlerCheck in libcamlrun.lib(intern.obj) #29 is probably related (I'm seeing this error only after upgrading to
ucrt.lib
. - Some extra libraries are needed (not sure whether this belongs in ocaml/flexdll or ocaml/ocaml itself). I'll place each library in a separate comment below.
Activity
jonahbeckford commentedon Sep 28, 2023
+ vcruntime.lib
Fixes:
jonahbeckford commentedon Sep 28, 2023
+ kernel32.lib
Fixes
Add separate libs alongside ucrt
nojb commentedon Sep 29, 2023
Sorry for the naïve question, but to make sure I understand: are we speaking here of linking the executables produced by flexlink/MSVC against
ucrt
? Somehow I remember that ever since switching to VS 2015, the executables produced by the OCaml comiler (via flexlink/MSVC) already depended on ucrt? I must be missing something...jonahbeckford commentedon Sep 29, 2023
The issue is that
msvcrt
anducrt
don't always play nicely when linked into an executable. From what I understand, we are supposed to be able to mix/match the old C runtime and the Universal C runtime, but we still can get conflicts:Seems safer just not to link to the old
msvcrt
runtime when it is not needed. Caveat: I am still testing.A small summary is at https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt:
@nojb "the executables produced by the OCaml comiler (via flexlink/MSVC) already depended on ucrt? I must be missing something...".
I suspect the new thing in VS 2015 was that the binaries started to depend on
vcruntime140.dll
. If so, that is independent of MSVCRT versus UCRT.jonahbeckford commentedon Sep 29, 2023
+ Compiler Routines
I believe these are the last missing symbols to be resolved:
From what I can tell these aren't defined in libraries but are instead emitted by the compiler and/or linker. For example,
__chkstk
should be emitted by MSVC to implement/Gs<n>
: https://learn.microsoft.com/en-us/cpp/build/reference/gs-control-stack-checking-calls?view=msvc-170.I am currently puzzled by why these symbols are not present! My guesses so far:
link.exe
is inserting these routines, andflexlink.exe
is not doing the same?.obj
files, butflexlink.exe
is dropping these symbols for some weird reason.Edit 1:
_fltused
is answered by https://stackoverflow.com/a/1583220.flexlink.exe
will need to define this symbol but only if there is an external link to that symbol. The stackoverflow is incorrect though ... the real code isC:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\crt\src\vcruntime\fltused.cpp
and is defined to be0x9875
.Edit 2:
__chkstk
is defined inC:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.35.32215\crt\src\i386\chkstk.asm
,C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\crt\src\i386\chkstk.asm
(etc.).__chkstk
comes pre-compiled atC:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133
(etc.):Edit 3:
_setjmp
. I made a version https://github.com/diskuv/dkml-compiler/blob/main/src/f/setjmp.asm that can be included in github.com/ocaml/ocaml.All the above still needs testing
jonahbeckford commentedon Sep 30, 2023
+ msvcrt.lib (only for
.exe
link)Fixes:
Now it is weird that I am putting
msvcrt.lib
back in. But this is back not when linking DLLs; it is only back when linking.exe
(the only place where CRT initialization should occur). And if necessary we could write our own CRT initialization routine just likeflexdll/flexdll_initer.c
Lines 35 to 55 in cc0525e