I decided to experiment with the Microsoft Visual Studio 2015 release candidate. This bundle contains msvc-14.0 for which `_MSC_VER` has the value 1900.
Some warnings are silenced with this patch to byterun/floats.c
#if defined (_MSC_VER)
# include <float.h>
# if(MSC_VER < 1900)
# define isnan _isnan
# define isfinite _finite
# endif/*(MSC_VER <= 1400)*/
#endif /*defined(_MSC_VER)*/
There is a problem though that comes about here in the production of 'ocamlrun.exe':
link -lib -nologo -machine:AMD64 /out:libcamlrun.lib interp.obj misc.obj stacks.obj fix_code.obj startup_aux.obj startup.obj freelist.obj major_gc.obj minor_gc.obj memory.obj alloc.obj roots.obj globroots.obj fail.obj signals.obj signals_byt.obj printexc.obj backtrace.obj compare.obj ints.obj floats.obj str.obj array.obj io.obj extern.obj intern.obj hash.obj sys.obj meta.obj parsing.obj gc_ctrl.obj terminfo.obj md5.obj obj.obj lexing.obj callback.obj debugger.obj weak.obj compact.obj finalise.obj custom.obj dynlink.obj win32.obj main.obj
cl -nologo -D_CRT_SECURE_NO_DEPRECATE -DOCAML_STDLIB_DIR='"C:/ocaml-msvc14/lib"' -I"C:\Program Files (x86)\flexdll" -O2 -Gy- -MD -c -o prims.obj prims.c
cl : Command line warning D9035 : option 'o' has been deprecated and will be removed in a future release
prims.c
flexlink -x64 -merge-manifest -stack 33554432 -exe -o ocamlrun.exe prims.obj ws2_32.lib \
libcamlrun.lib
** Cannot resolve symbols for descriptor object:
__iob_func
sprintf
Makefile.nt:23: recipe for target 'ocamlrun.exe' failed
The second of those missing symbols 'sprintf' can be resolved with this addition to config/Makefile, line 99
EXTRALIBS=legacy_stdio_wide_specifiers.lib legacy_stdio_definitions.lib
so that the flexlink step reads
flexlink -x64 -merge-manifest -stack 33554432 -v -exe -o ocamlrun.exe prims.obj ws2_32.lib legacy_stdio_wide_specifiers.lib legacy_stdio_definitions.lib libcamlrun.lib
but the issue with '__iob_func' remains.
I've always associated this sort of problem in the past with mismatch between /MD and /MT. Research also indicates that this error can manifest when linking under msvc-14 against objects built with an older version of the compiler. In any case, after scratching around on it for an hour or two, I haven't yet found a way to overcome the link failure.
I don't know for sure whether we are looking at a problem with the release candidate or, a problem with the build system with this new compiler. I do have a lead or two left to follow - if I have any success at overcoming this problem, I'll post here.