Cannot make .obj on windows 10

[JacobGood1]

Makefile:

all: C:\mercury-14.01-vs2013\bin\merc.BAT --make libhello_world

Source file... hello_world.m:

:- module hello_world. :- interface.

:- import_module int. :- pred fib(int::in, int::out) is det.

:- implementation. :- pragma foreign_export("C", fib(in,out), "fib").

fib(N,X) :- ( if N =< 2 then X = 1 else fib(N-1,A), fib(N-2,B), X = A + B
).

Error message with nmake:

NMAKE : fatal error U1077: 'C:\mercury-14.01-vs2013\bin\merc.BAT' : return code '0x3' Stop.

Error message using gnu make through cygwin:

Making Mercury\objs\hello_world.obj Makefile:2: recipe for target 'all' failed make: *\ [all] Error 3

[juliensf]

Does it work if you invoke the compiler directly (i.e. not from a Makefile)?

It would also useful if you could arrange to pass --verbose-commands to the compiler so we can see what it is attempting to do.

[JacobGood1]

As long as I am not trying to create an .obj with the lib prefix, invoking the compiler directly works fine. I do no know how to invoke the compiler directly in a way to tell it to generate the .obj

I tried pre-pending lib to hello_world.m but that did not work(sorry, I am quite the nub). Can you tell me what commands I need to use to try and generate the .obj without a Makefile?

Here is what it says with the verbose setting in the Makefile...

Making Mercury\int3s\hello_world.int3 Making Mercury\ints\hello_world.int Invoking self mmc --invoked-by-mmc-make --libgrade none.gc.trseg.debug.stseg --libgrade none.gc.decldebug.stseg --libgrade none.gc.debug.stseg --libgrade none.gc --libgrade java --libgrade hlc.gc.trseg --libgrade hlc.gc.memprof --libgrade hlc.gc --libgrade csharp -O2 -- grade hlc.gc --mercury-linkage static --mercury-stdlib-dir C:/mercury-14.01-vs2013/lib/mercury --mercury-config-dir C:/mercury-14.01-vs2013/lib/mercury --cc cl --c-compiler-type cl_1800 --java-compiler javac --java-interpreter java --csharp-compiler csc --csharp-compiler -type microsoft --cli-interpreter "" --erlang-compiler "" --erlang-interpreter "" --cflags-for-ansi "" --cflags-for-optimization "" --cflags-for-warnings -nologo --cflags-for-threads "-DGC_WIN32_THREADS -MD" --cflags-for-debug "" --cflags-for-regs "" --cflags-for-gotos " " --cflags-for-pic "" --c-flag-to-name-object-file -Fo --java-flags -J"-Xmx1024m" --object-file-extension .obj --pic-object-file-extension .o --link-with-pic-object-file-extension .o --executable-file-extension .exe --shared-library-extension .lib --library-extension .li b --create-archive-command lib --create-archive-command-output-flag -OUT: --create-archive-command-flags -nologo --ranlib-command echo --ranlib-flags "" --link-executable-command cl --link-shared-lib-command "cl -shared" --trace-libs " " --thread-libs "" --hwloc-libs "" --hwloc-static-libs "" --shared-libs " -lc" --math-lib "" --readline-libs "" --linker-opt-separator -link --linker-thread-flags -MD --shlib-linker-thread-flags -MD --linker-trace-flags "" --shlib-linker-trace-flags "" --linker-static-flags "" --linker-strip-flag "" --li nker-debug-flags -DEBUG --shlib-linker-debug-flags -DEBUG --linker-link-lib-flag "" --linker-link-lib-suffix .lib --shlib-linker-link-lib-flag "" --shlib-linker-link-lib-suffix .lib --linker-path-flag -LIBPATH: --linker-rpath-flag -Wl,-rpath, --linker-rpath-separator " - Wl,-rpath," --shlib-linker-rpath-flag -Wl,-rpath, --shlib-linker-rpath-separator " -Wl,-rpath," --shlib-linker-install-name-flag "-install_name " --linker-allow-undefined-flag "" --linker-error-undefined-flag "" --fullarch i686-pc-mingw32 --install-prefix C:/mercury-14.0 1-vs2013 --num-real-r-regs 0 --num-real-r-temps 0 --conf-low-tag-bits 2 --bits-per-word 32 --bytes-per-word 4 --sync-term-size 0 --dotnet-library-version 4.0.0.0 --host-env-type windows --target-env-type windows --restricted-command-line --no-unboxed-float --max-jump-tab le-size 512 -O2 --no-use-symlinks --make --infer-all --verbose-commands --make-interface --use-subdirs hello_world' Making Mercury\cs\hello_world.c Invoking selfmmc --invoked-by-mmc-make --libgrade none.gc.trseg.debug.stseg --libgrade none.gc.decldebug.stseg --libgrade none.gc.debug.stseg --libgrade none.gc --libgrade java --libgrade hlc.gc.trseg --libgrade hlc.gc.memprof --libgrade hlc.gc --libgrade csharp -O2 -- grade hlc.gc --mercury-linkage static --mercury-stdlib-dir C:/mercury-14.01-vs2013/lib/mercury --mercury-config-dir C:/mercury-14.01-vs2013/lib/mercury --cc cl --c-compiler-type cl_1800 --java-compiler javac --java-interpreter java --csharp-compiler csc --csharp-compiler -type microsoft --cli-interpreter "" --erlang-compiler "" --erlang-interpreter "" --cflags-for-ansi "" --cflags-for-optimization "" --cflags-for-warnings -nologo --cflags-for-threads "-DGC_WIN32_THREADS -MD" --cflags-for-debug "" --cflags-for-regs "" --cflags-for-gotos " " --cflags-for-pic "" --c-flag-to-name-object-file -Fo --java-flags -J"-Xmx1024m" --object-file-extension .obj --pic-object-file-extension .o --link-with-pic-object-file-extension .o --executable-file-extension .exe --shared-library-extension .lib --library-extension .li b --create-archive-command lib --create-archive-command-output-flag -OUT: --create-archive-command-flags -nologo --ranlib-command echo --ranlib-flags "" --link-executable-command cl --link-shared-lib-command "cl -shared" --trace-libs " " --thread-libs "" --hwloc-libs "" --hwloc-static-libs "" --shared-libs " -lc" --math-lib "" --readline-libs "" --linker-opt-separator -link --linker-thread-flags -MD --shlib-linker-thread-flags -MD --linker-trace-flags "" --shlib-linker-trace-flags "" --linker-static-flags "" --linker-strip-flag "" --li nker-debug-flags -DEBUG --shlib-linker-debug-flags -DEBUG --linker-link-lib-flag "" --linker-link-lib-suffix .lib --shlib-linker-link-lib-flag "" --shlib-linker-link-lib-suffix .lib --linker-path-flag -LIBPATH: --linker-rpath-flag -Wl,-rpath, --linker-rpath-separator " - Wl,-rpath," --shlib-linker-rpath-flag -Wl,-rpath, --shlib-linker-rpath-separator " -Wl,-rpath," --shlib-linker-install-name-flag "-install_name " --linker-allow-undefined-flag "" --linker-error-undefined-flag "" --fullarch i686-pc-mingw32 --install-prefix C:/mercury-14.0 1-vs2013 --num-real-r-regs 0 --num-real-r-temps 0 --conf-low-tag-bits 2 --bits-per-word 32 --bytes-per-word 4 --sync-term-size 0 --dotnet-library-version 4.0.0.0 --host-env-type windows --target-env-type windows --restricted-command-line --no-unboxed-float --max-jump-tab le-size 512 -O2 --no-use-symlinks --make --infer-all --verbose-commands --compile-to-c --use-subdirs hello_world' Making Mercury\objs\hello_world.obj % Invoking system command `cl -I. -I. -I.\Mercury\mihs -IC:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\inc -IC:\mercury-14.01-vs2013\lib\mercury\conf -IC:\mercury-14.01-vs2013\lib\mercury\inc -DMR_HIGHLEVEL_CODE -DMR_CONSERVATIVE_GC -DMR_BOEHM_GC -DMR_TAGBITS=2 -nologo -c Mercury\cs\hello_world.c -FoMercury\objs\hello_world.obj'... NMAKE : fatal error U1077: 'C:\mercury-14.01-vs2013\bin\merc.BAT' : return code '0x3' Stop.

[juliensf]

You should be able to create an object file using:

 C:\> mercury --make hello_world.obj

What is merc.BAT? Have you just renamed mercury.bat or is it something else?

[JacobGood1]

mmc conflicts with microsoft management console so merc is the command for invoking the mercury compiler on my system.

merc --make hello_world.obj Making Mercury\objs\hello_world.obj

this produces no error, however, when I enter the objs folder to investigate what was created there is no hello_world.obj file.

[juliensf]

Hi,

Were there any generated .c files present in Mercury\cs? It looks like the error is occurring when the Mercury compiler attempts to invoke the C compiler, however I cannot replicate it on my system. Does invoking the C compiler directly on the command line work? That is, doing:

 cl -I. -I. -I.\Mercury\mihs -IC:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\inc -IC:\mercury-14.01-    vs2013\lib\mercury\conf -IC:\mercury-14.01-vs2013\lib\mercury\inc -DMR_HIGHLEVEL_CODE -DMR_CONSERVATIVE_GC -DMR_BOEHM_GC -DMR_TAGBITS=2
-nologo -c Mercury\cs\hello_world.c -FoMercury\objs\hello_world.obj

We're aware the of the conflict with the Microsoft Management Console; the batch file mercury.bat in the bin directory is provided as an alternative. Is your Merc.bat file doing something different from what that does? (Error 0x3 usually indicates that a path somewhere is not being found.)

[JacobGood1]

Were there any generated .c files present in Mercury\cs?

There is a hello_world.c file in the cs directory after running make.

Does invoking the C compiler directly on the command line work?

Copying and pasting the code that you gave me gives...

cl : Command line warning D9027 : source file '.obj' ignored hello_world.c c:\mercury-14.01-vs2013\lib\mercury\inc\mercury_std.h(23): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory

Is your Merc.bat file doing something different from what that does?

no, I changed it to mercury just to be sure and it gives me the same result

[JacobGood1]

Could I get any more help on this or do I need to seek another route? Either way thanks for persevering this long.

[juliensf]

Sorry for the delayed response. With regard to the above error (i.e. the D9027 one) that looks like a cut-and-paste error, probably a space inserted between the '-Fo' flag and its value. With respect to the original problem, I can't reproduce it at my end :-( There was a fix about a year ago for a problem where the Mercury compiler was not correctly interpreting the exit status of MSVC. Version 14.01 lacks that fix, which I suspect is contributing to the problem here. Are you using VS2013 or a later version?

You may want to look into using the MinGW or MinGW64 ports; most users of Mercury on Window use one of them rather than the MSVC port.

[JacobGood1]

I am using the compiler for 2015, which one are you using? If it is the case that you are using the older one I will try that, if that does not work I will get mingw and try that.

[juliensf]

The package was built against VS2013 on Windows 7.

[negatratoron]

I have the exact same problem. I downloaded "Mercury 14.01 (Visual Studio 2013 32bit)" installer from this page. I have Visual Studio 2017 installed on this machine. I'm getting the same behavior, with pretty much the same error: no exe is built, and the exit status is 3.

When I run mmc.bat --make hello in the directory containing my hello.m hello world program, I actually get the error 'cl' is not recognized as an internal or external command.

Adding the directory containing cl.exe to PATH, I get an error at the very same point that @JacobGood1 does, which is this:

C:\cygwin64\home\rofl\hello>mmc.bat --make hello -V

(SNIP)

Making Mercury\objs\hello.obj
% Compiling `Mercury\cs\hello.c':
% Invoking system command `cl -I. -I. -I.\Mercury\mihs -IC:\mercury-14.01-vs2013\lib\mercur\lib\hlc.gc\inc -IC:\mercury-14.01-vs2013\lib\mercury\conf -IC:\mercury-14.01-vs2013\lib\mercury\inc    -DMR_HIGHLEVEL_CODE -DMR_CONSERVATIVE_GC -DMR_BOEHM_GC -DMR_TAGBITS=2      -nologo    -c Mercury\cs\hello.c -FoMercury\objs\hello.obj'...

I tried building from the Developer Command Prompt that comes with Visual Studio, as it has extra environment variables set up, including knowing where cl.exe is without having to alter the system-wide PATH variable. From there, the build gets further but stops at a different point:

C:\cygwin64\home\rofl\hello>mmc.bat --make hello -V

(SNIP)

% Invoking system command `cl        -Fehello.exe C:\Users\rofl\AppData\Local\Temp\mtmp001.486.lib -link -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc      -nologo -subsystem:console -machine:x86 -entry:wmainCRTStartup -defaultlib:libcmt     C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_std.lib C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_rt.lib C:\mercury-14.01-vs2013\lib\mercury\lib\libgc.lib    '...

Running the command directly to see the errors that cl is throwing:

C:\cygwin64\home\rofl\hello>cl        -Fehello.exe C:\Users\rofl\AppData\Local\Temp\mtmp001.62A.lib -link -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib -LIBPATH:C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc      -nologo -subsystem:console -machine:x86 -entry:wmainCRTStartup -defaultlib:libcmt     C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_std.lib C:\mercury-14.01-vs2013\lib\mercury\lib\hlc.gc\libmer_rt.lib C:\mercury-14.01-vs2013\lib\mercury\lib\libgc.lib
LINK : warning LNK4001: no object files specified; libraries used
libmer_rt.lib(mercury_type_info.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_rt.lib(mercury_runtime_util.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_rt.lib(mercury_memory_handlers.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_rt.lib(mercury_getopt.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_rt.lib(mercury_trace_base.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_rt.lib(mercury_wrapper.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_rt.lib(mercury_misc.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_rt.lib(mercury_regs.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_std.lib(io.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_std.lib(benchmarking.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_std.lib(robdd.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_std.lib(table_builtin.obj) : error LNK2001: unresolved external symbol ___iob_func
libmer_std.lib(io.obj) : error LNK2019: unresolved external symbol _vfprintf referenced in function _ML_fprintf
libmer_rt.lib(mercury_misc.obj) : error LNK2001: unresolved external symbol _vfprintf
libmer_rt.lib(mercury_memory_zones.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_rt.lib(mercury_float.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_rt.lib(mercury_bitmap.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_rt.lib(mercury_deep_copy.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_rt.lib(mercury_deconstruct.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_std.lib(io.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_std.lib(float.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_rt.lib(mercury_trace_base.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_rt.lib(mercury_ho_call.obj) : error LNK2001: unresolved external symbol _sprintf
libmer_std.lib(io.obj) : error LNK2019: unresolved external symbol _vsprintf referenced in function _mercury_io_error
libmer_rt.lib(mercury_float.obj) : error LNK2001: unresolved external symbol _sscanf
libmer_std.lib(lexer.obj) : error LNK2001: unresolved external symbol _sscanf
libmer_std.lib(parsing_utils.obj) : error LNK2001: unresolved external symbol _sscanf
libmer_std.lib(string.obj) : error LNK2001: unresolved external symbol _sscanf
libmer_rt.lib(mercury_wrapper.obj) : error LNK2001: unresolved external symbol _sscanf
libmer_rt.lib(mercury_tabling.obj) : error LNK2019: unresolved external symbol _printf referenced in function _MR_table_type_back
libmer_rt.lib(mercury_layout_util.obj) : error LNK2001: unresolved external symbol _printf
libmer_rt.lib(mercury_memory_handlers.obj) : error LNK2001: unresolved external symbol _printf
libmer_std.lib(region_builtin.obj) : error LNK2001: unresolved external symbol _printf
libmer_std.lib(table_builtin.obj) : error LNK2001: unresolved external symbol _printf
libmer_rt.lib(mercury_trace_base.obj) : error LNK2001: unresolved external symbol _printf
libmer_rt.lib(mercury_wrapper.obj) : error LNK2001: unresolved external symbol _printf
libmer_rt.lib(mercury_trace_base.obj) : error LNK2019: unresolved external symbol __snprintf referenced in function _MR_trace_record_label_exec_counts
libmer_rt.lib(mercury_wrapper.obj) : error LNK2001: unresolved external symbol __snprintf
libmer_rt.lib(mercury_string.obj) : error LNK2019: unresolved external symbol _vsnprintf referenced in function _MR_make_string
libcmt.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol _vsnprintf
libgc.lib(misc.obj) : error LNK2019: unresolved external symbol __vsnprintf referenced in function _GC_printf
libcmt.lib(vsnprintf.obj) : error LNK2001: unresolved external symbol __vsnprintf
hello.exe : fatal error LNK1120: 9 unresolved externals

According to Google, linking with legacy_stdio_definitions.lib should fix most of the link errors, but fixing the ___iob_func ones looks a little more involved. (Note the 3 underscores in the error as opposed to the 2 in that stackoverflow link).

I tried appending both legacy_stdio_definitions.lib __iob_lib.lib, and legacy_stdio_definitions.lib __iob_lib.lib Mercury/objs/hello.obj in case the warning emitted by cl was important, to that last cl command, where __iob_lib.lib is a lib I built containing the code in smartsl's answer on that stackoverflow post, and both generated exe files, but both segfaulted.

[eazar001]

Was this issue resolved? I'd be curious to know what was the agreed upon solution as I could not get the build working in msys2. I also tried the Windows installer which also does not integrate with cl.exe and MSVS 2017 out of the box either. Builds on msys2 fail rather silently with error 2 and little output.

[eazar001]

I came up with a dumb workaround. As mysys2 repos apparently don't provide the 4.8 version (which, according to the release notes, it's built for compatibility with) of the gcc toolchain, I was essentially forced to download the ROTD version of mercury, rather than the stable variant. The build, and subsequently, the mercury compile,r works and integrates with Windows 10 after this.

[juliensf]

Mercury 14.X definitely won't work with recent updates of Windows 10. There have been some changes to the virtual memory subsystem that break the version of the Boehm collector that shipped with Mercury 14.X. (Recent ROTDs have an updated garbage collector and are fine on Windows.)

[eazar001]

I see. Thanks, that explains it. Is there a new stable release planned any time soon?

[juliensf]

There aren't any definite plans for a release at the moment. There are few large pieces of work that would definitely need to be completed / stabilize before we would consider that. The ROTDs are quite stable (for the most part), so unless there's a strong reason to require 14.X I suggest using them.

[wangp]

I was thinking we should move to a more, um, relaxed release process so releases can be made more frequently. We keep the master branch in a better state than the last release branch anyway, except that bugs may slip through so you may happen to get a bad ROTD. Perhaps every so often (quarter? half year?) we can retroactively pick a known good ROTD and promote that on the download page.

Or we go a step further and make a "release" from the same commit as a good ROTD. For a regular release schedule to work, the amount of manual work that is involved needs to be minimised.

[eazar001]

Definitely some good ideas there.