Cannot make .obj on windows 10 #38
Comments
|
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. |
|
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 |
|
You should be able to create an object file using: What is merc.BAT? Have you just renamed mercury.bat or is it something else? |
|
mmc conflicts with microsoft management console so merc is the command for invoking the mercury compiler on my system. merc --make 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. |
|
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. 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.) |
There is a hello_world.c file in the cs directory after running make.
Copying and pasting the code that you gave me gives... cl : Command line warning D9027 : source file '.obj' ignored
no, I changed it to mercury just to be sure and it gives me the same result |
|
Could I get any more help on this or do I need to seek another route? Either way thanks for persevering this long. |
|
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. |
|
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. |
|
The package was built against VS2013 on Windows 7. |
|
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 Adding the directory containing I tried building from the Developer Command Prompt that comes with Visual Studio, as it has extra environment variables set up, including knowing where Running the command directly to see the errors that According to Google, linking with I tried appending both |
|
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 |
|
I came up with a dumb workaround. As |
|
Mercury 14.X definitely won't work with recent updates of Windows 10. There have been |
|
I see. Thanks, that explains it. Is there a new stable release planned any time soon? |
|
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. |
|
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. |
|
Definitely some good ideas there. |
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
The text was updated successfully, but these errors were encountered: