Windows make - make (e=2): The system cannot find the file specified - windows

I'm using the C++ SFML Library on Windows with Visual Studio Code. The clean target is causing an error message to display and I'm wondering what's happening and how I can fix it. This particular project is just my setup project to ensure things are working. My working directory is as follows:
TEST
Main.cpp
Makefile
My Makefile is the following and I'm using mingw32-make. It creates Main.o and Main.exe. For my question, you can ignore most things, my question is in regards to the clean target.
# Makefile for static linking.
CXX = g++
CXXFLAGS =
EXE = Main
OBJ = Main.o
MODULES = -lsfml-graphics-s -lsfml-window-s -lsfml-system-s -lopengl32 -lfreetype -lwinmm -lgdi32 -mwindows
HEADERS = -IC:\SFML\include -DSFML_STATIC
LIBRARIES = -LC:\SFML\lib
$(EXE): $(OBJ)
$(CXX) $(CXXFLAGS) -o $(EXE) $(OBJ) $(LIBRARIES) $(MODULES)
Main.o: Main.cpp
$(CXX) $(CXXFLAGS) -c Main.cpp -o Main.o $(HEADERS)
clean:
rm $(EXE) $(OBJ)
I am able to compile and run the program but when I do the clean target, I get the following error message.
rm Main Main.o
process_begin: CreateProcess(NULL, rm Main Main.o, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make: *** [Makefile:17: clean] Error 2
I thought the issue might be that the ".exe" file extension is not present because if I manually enter "rm Main" I get another error message.
rm : Cannot find path 'C:\Users\Benjamin\PROGRAMMING_PROJECTS\CPP_PROJECTS\SFML_VSCode\TestNoCMake\Main' because it does not exist.
At line:1 char:1
+ rm Main
+ ~~~~~~~
+ CategoryInfo : ObjectNotFound: (C:\Users\Benjam...estNoCMake\Main:String) [Remove-Item], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
But if I change it to "rm Main.exe" it deletes the file successfully. Upon seeing that, I tried editing my Makefile to have the ".exe" in it.
clean
rm $(EXE).exe $(OBJ)
But, I still end up getting the image in the first picture.
Why is this happening and how can I fix this?
I've seen some other questions about this particular error but they weren't helpful. My setup is also based on this youtube tutorial (https://www.youtube.com/watch?v=rZE700aaT5I&t=96s) and the person in the video did not have this issue. However, his tutorial did not cover the part where MinGW and make are installed, so maybe his and mine are different and it's causing the issue.

The error you're seeing is because the rm program is not found. It's not found because rm is a POSIX tool, and you are running on Windows. The GNU Make program on Windows can be built in various different ways, but the way you have built it means that when it wants to run a shell script it is invoking Windows cmd.exe as its shell.
The output you show from running the command "by hand" shows you are running it from PowerShell, not from cmd.exe so that's probably why you're seeing different behaviors.
You likely need to investigate the PATH variable and ensure that your POSIX tools appear in some directory on the PATH, if you want to write makefiles that use them.
Also I should mention, when writing makefiles you really always want to use forward slashes (/) and never backslashes when you are writing pathnames.

Related

Linker Option with 1.0 in name Windows

I am trying to create a program using the libusb-1.0 library
After I installed the library when I try to compile like so
gcc -g main.c -o test.exe -lusb-1.0
i get the following error
gcc.exe: error: .0: No such file or directory
what do I have to type for the linkage option "-lusb-1.0" to be read properly
I am using mingw64 on Windows
This can be solved by adding single or double quotes around '-lusb-1.0'
for example here is the code i used to compile
gcc *.c -o test.exe '-lusb-1.0'

How do I compile fortan code on a cluster using a given build file

I want to run a Fortran code on a cluster. This is to run a test case where all the needed files for the test case are provided.
I have uploaded all the files in a directory on the cluster. Among the files is a "build" file (the content of which is below) that seems to compile the code I want with specific flags using an Intel compiler. I don't know what file type it is (pop os sees it as an audio file which is not very helpful) and I don't know what bash command to use to make it compile the Fortran code.
I have tried build myfortrancode.f90 and make build but I get command not found for build and nothing to be done for build using make (and I guess it makes sense since there are no "make" files.) I have also checked the .pbs file that comes with the test case but as expected it doesn't refer to this build file.
ifort -O2 -r8 -fpe0 -g -traceback -c myFortranCode.f90
ifort -O2 -r8 -fpe0 -g -traceback -o myFortranCode myFortranCode.o
rm -f *.mod *.o
Try the bash command below to run all commands in your "build" file.
source build
Or you can add execute permissions to build and run it with the following bash commands:
chmod 775 build
./build

CMake-generated MinGW Makefile has quoting errors

I was trying to build zlib with CMake 3.9.0, output set to MinGW Makefiles, and noticed upon trying to call mingw32-make in the output dir that there was a weird error message which very much looks like a quoting error to me.
D:\zlib-1.2-11> mingw32-make
[ 2%] Generating zlib1rc.obj
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files\mingw-w64\x86_64-7.1.0-win32-seh-rt_v5-rev0\mingw64\bin\windres.exe: preprocessing failed.
CMakeFiles\zlib.dir\build.make:60: recipe for target 'zlib1rc.obj' failed
mingw32-make[2]: *** [zlib1rc.obj] Error 1
CMakeFiles\Makefile2:103: recipe for target 'CMakeFiles/zlib.dir/all' failed
mingw32-make[1]: *** [CMakeFiles/zlib.dir/all] Error 2
Makefile:139: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
What could be the cause of this error and how can I fix it? If it were only zlib, I could scrape the net for pre-built binaries, but this has happened with some other builds, too.
This appears to be a bug in MinGW's version of windres.exe, although I'm also going to heap some blame onto CMake for it's appalling method of invoking windres, which is what is causing this to fail.
The Problem
CMake understands that Windows Resource .rc files are a thing, and that they are compiled with the Windows Resource Compiler (aka windres.exe), which it wraps in the default variable CMAKE_RC_COMPILER.
The problem is, that rather than just invoking windres like a normal person, CMake thinks it's being clever by invoking it like so...
cmd.exe /C "cd /D C:\Users\username\zlib-1.2.11\build && "C:\Program Files\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev0\mingw64\bin\windres.exe" -D GCC_WINDRES -I C:/Users/username/zlib-1.2.11 -I C:/Users/username/zlib-1.2.11/build -o C:/Users/username/zlib-1.2.11/build/zlib1rc.obj -i C:/Users/username/zlib-1.2.11/win32/zlib1.rc"
Evidently it doesn't understand the notion of the current working directory, or the system path variable (which it used to find windres in the first place). If we were to simplify the command, it would look like this...
windres -D GCC_WINDRES -I.. -I. -ozlib1rc.obj -i ../win32/zlib1.rc
Those two commands carry the exact same meaning, except the second one actually works.
The Solution
We have to step in and stop CMake from trying to be clever.
cmake .. -DCMAKE_RC_COMPILER=windres
I have MSVC 2017 installed, and CMake assumes that I want to use that by default, despite none of its environment variables being set and it not being in the path (in normal usage, one must invoke the vcvars64.bat file before using MSVC, this behaviour predates CMake). So I have to use -G "MinGW Makefiles", except that I also have sh.exe in my path (because Git), and that just blows CMake's mind, so I need the command...
cmake .. -G"MSYS Makefiles" -DCMAKE_RC_COMPILER=windres
The CMake file author should have quoted strings containing unknown filesystem paths, i.e. variables and the VERBATIM option also avoids headaches:
if(MINGW)
# This gets us DLL resource information when compiling on MinGW.
if(NOT CMAKE_RC_COMPILER)
set(CMAKE_RC_COMPILER windres.exe)
endif()
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj"
COMMAND "${CMAKE_RC_COMPILER}"
-D GCC_WINDRES
-I "${CMAKE_CURRENT_SOURCE_DIR}"
-I "${CMAKE_CURRENT_BINARY_DIR}"
-o "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj"
-i "${CMAKE_CURRENT_SOURCE_DIR}/win32/zlib1.rc"
VERBATIM)
set(ZLIB_DLL_SRCS "${CMAKE_CURRENT_BINARY_DIR}/zlib1rc.obj")
endif(MINGW)

Broken Makefile after porting from linux to windows

I have a very simple makefile that I ported from Linux to Windows
it only goes inside subfolders and calls other makefiles
all:
$(MAKE) clean
#(cd apps; $(MAKE))
clean:
cd apps; $(MAKE) clean;
the problem is that I don't understand how the #(command1; command2; command3;) syntax works and I'm unable to make it work even with the simplest of commands
For instance
all:
dir
works fine and it outputs the contents of the directory (and I'm in the right one)
all:
cd apps; dir
Does not work, it outputs
cd apps; dir The system cannot find the path specified.
Even worse if I keep the parentheses:
all:
#(dir)
outputs
process_begin: CreateProcess(NULL, (dir), ...) failed. make (e=2): The
system cannot find the file specified.
Can somebody please point me to the proper documentation? I know it must be very simple but all the guesswork so far failed and the documentation is too huge to read it all. I tried but I couldn't find what I'm looking for
Thanks

Visual Studio Compiler and recursive Make

I've got a really scary error message while using the visual studio compiler with recursive make.
This is my setup:
Top level Makefile:
.PHONY: test
test:
$(MAKE) -C subdir
Makefile in subdir:
.PHONY: all
all:
cl.exe /nologo /c src/interface.cpp
The compilation succeeds but I always recieve this warning:
unrecognized source file type 'cl', object file assumed
This warning only appears when I invoke make using the top level Makfile. If I change the directoy to subdir and run make no error appears.
cl.exe is known to make by running vcvarsall.bat before running make.
I really hope you can help me.
Thanks in advance.
The problem was, that I had a variable holding the filename of the compiler and I exported that variable from Make. So the command was cl.exe cl.exe... Thanks!

Resources