I'm running make on my project on WIN7 PC and getting the following error:
make: Interrupt/Exception caught (code = 0xc0000005, addr = 0x0040b0ac)
when removing some make parts it seems as the following line is the problematic:
$(shell if exist $(1) echo YES)
Any ideas what seems to be the issue? solutions?
Thanks!
Update:
I'm working with gnu make 3.81.1 mingw32 , same make and makefile used to work on my previous WIN XP (32 bit), problem appeared after upgrading to WIN7 .
OK, I think I've got it.
Apparantly it is something related to the PATH, if I replace the "shell" command with a predefined :
_SHELL=C:/Windows/System32/cmd.exe
the problem is fixed. might be because of severl c:\Program Files PATH instances .
Upgrading to 3.82 fixes the issue as well so I guess the've fixed that
Thanks!
There are a number of different ways GNU make can be built for windows, and the different ways will use different shells for the $(shell ...) command. I don't actually know if any of them will ever invoke Windows command.com or not.
But in any event, it doesn't seem like your version of GNU make works properly in that way. You should update your question with where you got your GNU make from (cygwin? mingw?) or how you built it, if you built it yourself.
Also you might ask on the make-w32#gnu.org mailing list, where Windows users of GNU make hang out.
Related
I have a Makefile with a target that prepends an environment variable to the shell call (with the usual bash syntax). This is the gist of it:
mytest:
ANSWER=42 echo Hello!
(the real deal is a programme that does something with the ENV ANSWER, but that's irrelevant here)
This works as expected in a linux/bash environment. In windows/cmd.exe environments it works to my surprise in some machines, but fails in others with this error:
> make mytest
MYVAR=42 echo Hello!
'MYVAR' is not recognized as an internal or external command,
operable program or batch file.
make: *** [Makefile:332: mytest] Error 1
Which is what I'd normally expect, since ENVVAR=<value> <command> isn't valid syntax in the windows shell. Apparently Make does some magic that I don't understand.
If I pre-export the ENV this way, it works as expected:
mytest: export ANSWER:=42
mytest:
echo Hello!
But since it works on some windows environments, I'd like to know why and maybe adapt those instead of changing a lot of Makefiles.
All of the environments are using GNU Make version 4.3.
Running on Windows is complicated because GNU make can be built in different ways there. Sometimes it is built to use Windows cmd.exe as its shell. Sometimes it's built to use an installation of sh.exe as its shell (note, GNU make never comes with a shell: the shell is a separate facility provided on the system). And sometimes it's built to use sh.exe if it can find one, else use cmd.exe.
If you're seeing different behaviors on different systems, then the way make was built is different between those systems, and/or different systems have different extra software installed so that some have sh.exe and some don't.
The title says it all really, I run gfortran to compile a simple test fortran program, it compiles with no errors; but when I run ls to look at the output, there is no executable created. I've tried with the -o option set as well.
The fotran program is a simple hello world
program test1
implicit none
print *, "Hello World!"
end program test1
(The gfortran I'm using is from the mingw release; I have aliased gfortran to c:/mingw/bin/gfortran.exe within powershell, but the same problem happens if I call it explicitly)
Has anyone had this problem before? I thought it might be a permissions issue but I can create files from powershell just fine (unless gfortran needs additional permissions for some reason?). Any help greatly appreciated, thanks :)
Turns out simply aliasing the path to the compiler doesn't work in powershell for MinGW, adding the mingw bin directory to the path is necessary and solved my problem as #cup suggested in the comments. Thanks everyone :)
I just happened to have the same problem that you described but two years later ...
I found that I just need to call the program as ./test.exe instead of test.exe, as I would have done with MS-DOS. That way I do not have to change the path if I work in a different folder.
I noticed that, if sh.exe is present in the PATH, then mingw32-make will use it to launch commands. But if it is not, then it will use cmd.exe. The problem is that both application are .... completely incompatible, and there is no way to create makefiles to would work for both.
Is there a way to ask mingw32-make to always use cmd.exe? Or to create an environment forcing mingw32-make to ignore this sh.exe?
Turns out, I found the solution by chance. I had read that mingw32-make is supposed to look at the SHELL environment variable ... but it doesn't! However, you can specify the option on the command line like so:
mingw32-make SHELL=cmd
This is not ideal, but the best I could come up with. For now, I will leave this question un-answered, in case someone comes with a better answer.
I had similar issue, and resolved it by launching the make from a batch file, but before calling the make added:
set PATH... with only the necessary roots.
git-slave documentation only has the following not-so-helpful comment regarding installation on Windows:
* Limited windows support
Multiple users have been successful in using gitslave with Windows.
This is "supported" only in the sense that people have reported it to
work and we accept bugfixes, not that you can `make` install or check,
or that it is QAed on this platform prior to release."
When I try to download and run 'nmake install' I get the equally cryptic error:
makefile(2) : fatal error U1001: syntax error : illegal character '{' in macro
Stop.
Does anyone have any experience with this and can point me in the right direction?
The Makefile for git-slave has only been used with GNU Make - as it is a rather simple makefile, there is no reason it shouldn't work with Microsoft nmake as well, except for "gratuitous" use of Make extensions that are not supported by Microsoft nmake. ( How similar/different are gnu make, microsoft nmake and posix standard make? has a good summary of the differences).
On lines 2-4 of gitslave/Makefile, if you replace ${prefix} with $(prefix) and ${mandir} with $(mandir) [essentially replace braces with parentheses (brackets)] nmake should no longer choke on Makefile. However, unless you have installed a bunch of POSIX utilities or something that allows commands like mkdir -p, rm -f, and sed to work, fixing the nmake incompatibility would only allow (at best) make testcheck to work.
None of the gitslave developers have regular(?) access to Windows development machines, so like the documentation says: "we accept bugfixes, [but do] not [claim] that you can make install or check,
or that it is QAed on this platform."
I imagine that the other people who have used git-slave on windows just made sure that Perl and gitslave and any POSIX utilities that gitslave depends on (e.g. grep and rm) are installed somewhere in PATH.
On Windows you can download and install the free unix tool kit including all necessary programs:
https://sourceforge.net/projects/unxutils/
You also need a perl tool kit because "pod2man" is used in the make process.
Furthermore the script "gits" is a perl script which runs under *ix because of the "she-bang" instruction in the first line ("#!/usr/bin/perl") - this doesn't work on Windows.
I created a small wrapper batch scripts that uses my perl to start the original script:
gits.bat:
perl gits %*
Hope this helps.
I’m writing a LaTeX package which needs to use \write18. Some of the shell commands I issue are system-specific (e.g. rm vs. del). Is there a way to determine what system I’m running on?
It would be enough to disambiguate between Windows and other (Unix-like) systems.
Take a look at the LaTeX ifplatform package. There was a lot of discussion about reliable methods across a range of platforms, and the current release works very well.
Not very good but it works for me
\newread\checkf
\immediate\openin\checkf = C:/WINDOWS/win.ini
\ifeof\checkf not windows \else windows\fi
\closein\checkf
If you can mark your OS with a file you can do
\IfFileExists{/etc/motd}{unix code here}{windows code here}
There's nothing special about the path /etc/motd; it's just likely to be found on a Unix system and unlikely on a Windows system. If you want to be dead certain, you should create a file specifically to mark the system in whatever way you want to identify it.
A friend of mine had the following idea which I’m now using. I’ve only tested it on Windows XP and OS X where it works fine. A bit flimsy on testing, admittedly, but in principle it should work fine almost anywhere else.
\newif\ifwindows
\immediate\write18{echo $SHELL > \jobname.os}
\newread\#whichos
\immediate\openin\#whichos\jobname.os
\read\#whichos to \#whichosshell
\ifthenelse{\equal{\#whichosshell}{$SHELL }}
{\windowstrue}
{\windowsfalse}
\closein\#whichos
\ifwindows
\typeout{System detected: Windows}
\newcommand\DeleteFile[1]{\immediate\write18{del #1}}
\else
\typeout{System detected: Unix-like}
\newcommand\DeleteFile[1]{\immediate\write18{rm #1}}
\fi
% Cleanup.
\DeleteFile{\jobname.os}
The key here is that Windows won’t expand the $SHELL environment variable (any other variable would have done, really) so it will write the string $SHELL to the file literally.