From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 1AEB87EEEF for ; Wed, 24 Jun 2015 17:25:28 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of shayne.fletcher.50@gmail.com) identity=pra; client-ip=209.85.216.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="shayne.fletcher.50@gmail.com"; x-sender="shayne.fletcher.50@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of shayne.fletcher.50@gmail.com designates 209.85.216.45 as permitted sender) identity=mailfrom; client-ip=209.85.216.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="shayne.fletcher.50@gmail.com"; x-sender="shayne.fletcher.50@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-vn0-f45.google.com) identity=helo; client-ip=209.85.216.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="shayne.fletcher.50@gmail.com"; x-sender="postmaster@mail-vn0-f45.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATDABfy4pVlC3YVdEaQYMwNV8GgxipG4YPjCyFfQKBQQdMAQEBAQEBEgEBAQEHCwsJHzAbAQGEBgEBAwESER0BGx0BAwELBgULNwICIgERAQUBDg4GEyKHdwEDCggNqkw+MYs/gWuCeYstChknDVeFCAEBAQEBAQEDAQEBAQEBAQEUAQUOgSeKFYUCBAeCaBKBMQWRKIJbAoRYhnmWbRIjgQ0JF4QlIjGCSAEBAQ X-IPAS-Result: A0ATDABfy4pVlC3YVdEaQYMwNV8GgxipG4YPjCyFfQKBQQdMAQEBAQEBEgEBAQEHCwsJHzAbAQGEBgEBAwESER0BGx0BAwELBgULNwICIgERAQUBDg4GEyKHdwEDCggNqkw+MYs/gWuCeYstChknDVeFCAEBAQEBAQEDAQEBAQEBAQEUAQUOgSeKFYUCBAeCaBKBMQWRKIJbAoRYhnmWbRIjgQ0JF4QlIjGCSAEBAQ X-IronPort-AV: E=Sophos;i="5.13,672,1427752800"; d="scan'208";a="167082588" Received: from mail-vn0-f45.google.com ([209.85.216.45]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jun 2015 17:25:27 +0200 Received: by vnbf7 with SMTP id f7so6811818vnb.13 for ; Wed, 24 Jun 2015 08:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nttC9QI4ByBYirsPUmVSRW/k9VuYuf9y4Nr48CiWwrU=; b=IyDMnmuqhm1nTdyl/kgZch3phhDGKEHZxahxmo74nrsg4Fe0gfvOmhyAOQOP0xk3X5 V54YXcD4iTm9IQlyFeuv9K7bwJ6h3DikHU16/JmJRTaulDny3DfUHrWqqdiZ6WsE2FOb xy5HaDpBse+xNDLrQLXh6d1k9rcRm85nLxLcTaaK5TdmJ0w4InPkOPj7gu+a+nXRWoTj TRTVKQEcr8e+wURel0OzIdizAxaciykcSNaqDX5l1jagcIfLwhEt73q0RRs64M6Aeua7 /gRR+kFCOQoeqb4OHbZpGiiPY3iLbE5/YSdy1vaKzjAaHD/8UJdnjB1Fe9rV3d+AWgpF finQ== X-Received: by 10.52.3.42 with SMTP id 10mr37481713vdz.10.1435159526086; Wed, 24 Jun 2015 08:25:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.92.134 with HTTP; Wed, 24 Jun 2015 08:25:06 -0700 (PDT) In-Reply-To: <558ABAA6.6070401@frisch.fr> References: <558ABAA6.6070401@frisch.fr> From: Shayne Fletcher Date: Wed, 24 Jun 2015 11:25:06 -0400 Message-ID: To: Alain Frisch Cc: "caml-list@inria.fr users" Content-Type: multipart/alternative; boundary=485b397dd613bf9e340519451dec Subject: Re: [Caml-list] Build failure under Visual Studio 2015 --485b397dd613bf9e340519451dec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 24, 2015 at 10:11 AM, Alain Frisch 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! > =E2=80=8BThis 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? --=20 Shayne Fletcher --485b397dd613bf9e340519451dec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 24, 2015 at 10:11 AM, Alain Frisch= <alain@frisch.fr> wrote:
This could come from .obj files shipp= ed with flexdll.=C2=A0 You could try to produce new versions of flexdll_msv= c.obj, flexdll_initer_msvc.obj (and the *msvc64.obj versions) by recompilin= g sources with MSVC 14.=C2=A0 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!

=E2=80=8BThis has indeed h= elped a bit. In my case I'm focusing on a 64-bit build so regenerated t= he objects with these commands

cl.exe /nologo /MD -D_CRT_SECURE_NO_= DEPRECATE /GS- /DMSVC =C2=A0-c /Fo"flexdll_msvc64.obj" flexdll.c<= /div>
c= l.exe /nologo /MD -D_CRT_SECURE_NO_DEPRECATE /GS- /DMSVC -c /Fo"flexdl= l_initer_msvc64.obj" flexdll_initer.c

That proved enough to get a build of 'ocaml_run= .exe'.=C2=A0We run into problems now at a later step:
=
flexlink -x64 -merge-manifest -stack 33554432 -exe -o tmpheader.ex= e headernt.obj legacy_stdio_wide_specifiers.lib legacy_stdio_definitions.li= b

Specifically, the link errors are=C2=A0

flexlin= k -x64 -merge-manifest -stack 33554432 -exe -o tmpheader.exe headernt.obj l= egacy_stdio_wide_specifiers.lib legacy_stdio_definitions.lib
flex= dll_msvc64.obj : error LNK2019: unresolved external symbol __imp___acrt_iob= _func referenced in function allow_write
flexdll_msvc64.obj : err= or LNK2019: unresolved external symbol __imp_fflush referenced in function = dump_symtbl
flexdll_msvc64.obj : error LNK2019: unresolved extern= al symbol __imp___stdio_common_vfprintf referenced in function _vfprintf_l<= /div>
flexdll_msvc64.obj : error LNK2019: unresolved external symbol __= imp___stdio_common_vsprintf referenced in function _vsnprintf_l
f= lexdll_msvc64.obj : error LNK2019: unresolved external symbol memcpy refere= nced in function cannot_resolve_msg
dyndlld1e979.obj : error LNK2= 001: unresolved external symbol memcpy
flexdll_msvc64.obj : error= LNK2019: unresolved external symbol strcmp referenced in function compare_= dynsymbol
dyndlld1e979.obj : error LNK2001: unresolved external s= ymbol strcmp
flexdll_msvc64.obj : error LNK2019: unresolved exter= nal symbol strlen referenced in function cannot_resolve_msg
dyndl= ld1e979.obj : error LNK2001: unresolved external symbol strlen
fl= exdll_msvc64.obj : error LNK2019: unresolved external symbol __imp_free ref= erenced in function flexdll_dlclose
flexdll_msvc64.obj : error LN= K2019: unresolved external symbol __imp_malloc referenced in function flexd= ll_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 reference= d in function allow_write
flexdll_msvc64.obj : error LNK2019: unr= esolved external symbol __imp__putenv_s referenced in function flexdll_dlop= en
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
<= br>link /nologo /verbose =C2=A0/implib:"C:\cygwin\tmp\dyndll_implib6ce= 752.lib" /out:"tmpheader.exe" /subsystem:console "C:\Pr= ogram Files (x86)\flexdll\flexdll_msvc64.obj" "headernt.obj"= "C:\cygwin\tmp\dyndll15a7c1.obj" /base:0x10000 msvcrt.lib

Any ideas?

--=C2=A0
Shayne Fletcher
--485b397dd613bf9e340519451dec--