[Caml-list] Build failure under Visual Studio 2015

[Caml-list] Build failure under Visual Studio 2015

[Shayne Fletcher]

[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]

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.

-- 
Shayne Fletcher

[-- Attachment #2: Type: text/html, Size: 6072 bytes --]

Re: [Caml-list] Build failure under Visual Studio 2015

[Alain Frisch]

Hi Shayne,

This could come from .obj files shipped with flexdll.  You could try to 
produce new versions of flexdll_msvc.obj, flexdll_initer_msvc.obj (and 
the *msvc64.obj versions) by recompiling sources with MSVC 14.  Sources 
can be found:

https://github.com/alainfrisch/flexdll

See also the Makefile for build instructions on these .obj files.

Let us know how this goes!

Alain



On 06/24/2015 03:39 PM, Shayne Fletcher wrote:
> 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.
>
> --
> Shayne Fletcher

Re: [Caml-list] Build failure under Visual Studio 2015

[Shayne Fletcher]

[-- Attachment #1: Type: text/plain, Size: 3333 bytes --]

On Wed, Jun 24, 2015 at 10:11 AM, Alain Frisch <alain@frisch.fr> wrote:

> This could come from .obj files shipped with flexdll.  You could try to
> produce new versions of flexdll_msvc.obj, flexdll_initer_msvc.obj (and the
> *msvc64.obj versions) by recompiling sources with MSVC 14.  Sources can be
> found:
>
> https://github.com/alainfrisch/flexdll
>
> See also the Makefile for build instructions on these .obj files.
>
> Let us know how this goes!
>

​This has indeed helped a bit. In my case I'm focusing on a 64-bit build so
regenerated the objects with these commands

cl.exe /nologo /MD -D_CRT_SECURE_NO_DEPRECATE /GS- /DMSVC  -c
/Fo"flexdll_msvc64.obj" flexdll.c
cl.exe /nologo /MD -D_CRT_SECURE_NO_DEPRECATE /GS- /DMSVC -c
/Fo"flexdll_initer_msvc64.obj" flexdll_initer.c

That proved enough to get a build of 'ocaml_run.exe'. We run into problems
now at a later step:

flexlink -x64 -merge-manifest -stack 33554432 -exe -o tmpheader.exe
headernt.obj legacy_stdio_wide_specifiers.lib legacy_stdio_definitions.lib

Specifically, the link errors are

flexlink -x64 -merge-manifest -stack 33554432 -exe -o tmpheader.exe
headernt.obj legacy_stdio_wide_specifiers.lib legacy_stdio_definitions.lib
flexdll_msvc64.obj : error LNK2019: unresolved external symbol
__imp___acrt_iob_func referenced in function allow_write
flexdll_msvc64.obj : error LNK2019: unresolved external symbol __imp_fflush
referenced in function dump_symtbl
flexdll_msvc64.obj : error LNK2019: unresolved external symbol
__imp___stdio_common_vfprintf referenced in function _vfprintf_l
flexdll_msvc64.obj : error LNK2019: unresolved external symbol
__imp___stdio_common_vsprintf referenced in function _vsnprintf_l
flexdll_msvc64.obj : error LNK2019: unresolved external symbol memcpy
referenced in function cannot_resolve_msg
dyndlld1e979.obj : error LNK2001: unresolved external symbol memcpy
flexdll_msvc64.obj : error LNK2019: unresolved external symbol strcmp
referenced in function compare_dynsymbol
dyndlld1e979.obj : error LNK2001: unresolved external symbol strcmp
flexdll_msvc64.obj : error LNK2019: unresolved external symbol strlen
referenced in function cannot_resolve_msg
dyndlld1e979.obj : error LNK2001: unresolved external symbol strlen
flexdll_msvc64.obj : error LNK2019: unresolved external symbol __imp_free
referenced in function flexdll_dlclose
flexdll_msvc64.obj : error LNK2019: unresolved external symbol __imp_malloc
referenced in function flexdll_dlopen
flexdll_msvc64.obj : error LNK2019: unresolved external symbol
__imp_bsearch referenced in function find_symbol
flexdll_msvc64.obj : error LNK2019: unresolved external symbol __imp_exit
referenced in function allow_write
flexdll_msvc64.obj : error LNK2019: unresolved external symbol
__imp__putenv_s referenced in function flexdll_dlopen
tmpheader.exe : fatal error LNK1120: 12 unresolved externals
** Fatal error: Error during linking

It appears to me that there is an underlying link command involved that
reads something like

link /nologo /verbose  /implib:"C:\cygwin\tmp\dyndll_implib6ce752.lib"
/out:"tmpheader.exe" /subsystem:console "C:\Program Files
(x86)\flexdll\flexdll_msvc64.obj" "headernt.obj"
"C:\cygwin\tmp\dyndll15a7c1.obj" /base:0x10000 msvcrt.lib

Any ideas?

-- 
Shayne Fletcher

[-- Attachment #2: Type: text/html, Size: 4680 bytes --]

Re: [Caml-list] Build failure under Visual Studio 2015

[Shayne Fletcher]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Wed, Jun 24, 2015 at 11:25 AM, Shayne Fletcher <
shayne.fletcher.50@gmail.com> wrote:

> We run into problems now at a later step:
>
> flexlink -x64 -merge-manifest -stack 33554432 -exe -o tmpheader.exe
> headernt.obj legacy_stdio_wide_specifiers.lib legacy_stdio_definitions.lib
>
> Specifically, the link errors are
>

​<...>​

I don't know if 'nodefaultlib' comes into play anywhere (reloc.ml)? There
is anecdotal evidence to suggest it doesn't play well with msvc-14 (
https://code.google.com/p/vim/issues/detail?id=357 and
http://stackoverflow.com/questions/29986585/why-am-i-not-able-to-build-vim-with-visual-studio-2015-rc-command-line-tools
).

-- 
Shayne Fletcher

[-- Attachment #2: Type: text/html, Size: 1707 bytes --]