mingw32 make: ***no rule to make target 'win32' stop - makefile

I am installing glfw forcodeblocks, when I try to execute the makefile through command prompt in order to compil glfw using this command:mingw32-make win32-mingw I get the following error mingw32 make: ***no rule to make target 'win32'. stop.
I am running a 64 bit version of windows 8

Edit:
For newer versions of glfw you can not use compile.bat or command mingw32-make win32-mingw
You must use CMake to create makefiles under the source folder e.g. build folder.
Then you can run mingw32-make .
For older versions :
Try it with the command described on the glfw side.
Unzip the archive anywhere you like (I will assume C:\glfw for simplicity).
Compile:
For Windows users, there is a batch file which allows to compile using a variety of compilers.
Open a DOS window, cd to the directory where GLFW lives (e.g. C:\glfw), and type
compile make mgw
Building the Libraries
As you can see there is a compile.bat
Of course you have to cd to your source folder. From an folder outside the source a compile.bat will not work.
if in your source there is no compile download it here.
glfw-2.5.zip

Related

How to Compile Ncurses Program for Native Windows Use

I'm trying to compile a C program using Ncurses on Windows. I compiled it successfully using GCC and it works perfectly if I run it in Cygwin or MSYS2. However, if I try to run it in the Windows Command Prompt, I get this error:
Error opening terminal: xterm-256color.
Is it possible to compile it to run using the native Windows console? This is how I've been compiling it:
gcc -o PROGRAMNAME main.c -lncurses
I also have the Cygwin and Msys dlls for Ncurses copied into the directory of the compiled executable.
Update
So I figured out how to get the program to run. I deleted all the DLLs from the project folder and then added "C:\msys64\usr\bin" to my PATH environment variable. However, I would still like to know if there's a way to get this to work if I were to distribute it, since it's still relying on my installation of MSYS2.
Update 2
Gave up and just used pdcurses and it works fine.
Update 3
Nevermind, found a solution! See below.
I figured out a solution. I'll post it here in case anyone else has this same issue. Thanks to Thomas Dickey for your help!
Install the mingw-w64 toolchain and any other packages you need to compile your project (this is mostly where I messed up)
Make sure to include the /mingw64/include/ncurses directory when compiling, or else gcc won't be able to find curses.h
Include /mingw64/bin as a static directory or copy over the necessary dlls to the same folder as the directory
I ended up with this to compile:
gcc -I/mingw64/include/ncurses -o PROGRAMNAME main.c -lncurses -L/mingw64/bin -static

SDL Linker error on mingw/msys: ld.exe cannot find -lSDL

Problem is actually that my compiler doesn't find the SDL library files. I rounded down possible errors by removing all SDL files, reinstalling SDL and compiling without SDL_image. No help.
Files I copied from SDL-devel-1.2.15-mingw32.tar.gz package:
sdl\include to mingw\include\sdl (I later copied files to mingw\include root as well)
sdl\lib to mingw\lib (3 files: libSDL.dll.a libSDLmain.a and libSDL.la)
sdl.dll and sdl-config to mingw\bin
I installed it via msys, and later manually just to make sure, and also copied same files to corresponding places in msys folder.
The error message:
c:/mingw/bin/../lib/gcc/mingw32/4.7.0/../../../../mingw32/bin/ld.exe: cannot find -lSDL
I have been using a simple make command in msys console, I moved the options for build into makefile to make things easier.
I'm using WinXP, MinGW/MSYS, SDL 1.2.15 and trying to compile fheroes2 source code.

gcc fails with spawn: No such file or directory

I downloaded
Ruben’s build of
Cygwin GCC.
However upon running it seems unable to compile any files
$ touch foo.c
$ gcc foo.c
gcc: error: spawn: No such file or directory
As a workaround, I found this to work
i686-w64-mingw32-gcc foo.c
I had the same problem and solved it by installing the g++ package in addition to gcc-core
I had this same problem on Cygwin64, and the solution was PATH related..kinda.
Turns out, there are copies of gcc in /usr/bin and /bin (at least, there is in my install).
Executing /bin/gcc failed with the error above -- I'm guessing due to incorrectly assumed relative paths???
Executing /usr/bin/gcc works as expected!
In my case, the "problem" was that I had inadvertently injected "/bin" into my PATH environment variable, resulting in /bin/gcc being executed, instead of /usr/bin/gcc. Removing the "/bin" from the path solved the problem.
Still unclear why there are two gcc binaries (which appear to be identical) in different places... but maybe the Cygwin gurus can answer that; or maybe my installation is just foo-barred.
Ruben's builds are not Cygwin GCC packages, rather they are cross-compilers which run on various platforms but target native Windows using the MinGW-w64 toolchain.
In any case, you shouldn't be using them on Cygwin. If you want to compile Cygwin executables, install the gcc4 packages; if you want to cross-compile for Windows, install the mingw64-i686-gcc (for Win32) or mingw64-x86_64-gcc (for Win64) packages instead.
Gcc isn't really the compiler. It's a front end program that orchestrates the execution of any necessary compiler, assembler, and linker components. Typically these others are separately compiled programs.
So, gcc is trying (kind of) to tell you that it can't find the compiler. I guess it needs to be on your PATH or in an expected location.
If you are executing this from a Windows DOS box then it definitely needs a windows PATH setting.
I like to install Cygwin, making sure to include rxvt. At that point, you can configure a purely sh(1) path and your environment is rather more civilized.
I had the same error when I tried to extract a couple of executables from cygwin installation dirctory and copied them into another location.
strace shows me the file which was not found by spawn:
/lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
When I copied cc1.exe into the location relative to
<dir with sh.exe and cpp.exe>/../lib/gcc/x86_64-pc-cygwin/6.4.0/cc1.exe
it works fine.
This error occurs whenever cygwin cc can't find a required file.
For those running stuff within cygwin's bin directly from a Windows shell, a gotcha to watch out for is that Windows allow you to run programs from the command line like this:
e:cyg/bin/gcc -flags
Notice that there is no slash between e: and cyg.
So this command would successfully start cygwin gcc from the Windows shell, but halfway through the run it will error out because some component(s) of gcc will utilize the first argument of the input e:cyg/bin/gcc and unlike mingw, this is not a valid path for cygwin gcc.
This can be fixed simply by changing the command to:
e:/cyg/bin/gcc -flags
Notice the slash in between e: and cyg.
A similar gotcha is due to Windows allowing paths like e:/../folder1 as an alternative to e:/folder1. Windows does not give you an error if you are at the root folder and try to go up another folder using ...
So you could start running cygwin gcc using the command:
e:/../cyg/bin/gcc -flags
..or even:
e:/../../../../../../../../../cyg/bin/gcc -flags
However, it would fail halfway with gcc: error: spawn: No such file or directory because some component(s) of cygwin gcc would attempt to run gcc using the first argument of the command input itself, and unlike mingw, e:/../cyg/bin/gcc is not recognized as a valid path by cygwin because you are going up a folder when there's no folder to go up to.
As like above, this can be fixed by keeping the path valid:
e:/cyg/bin/gcc -flags
Make sure the source file extension is in lowercase (i.e. main.c, not main.C):
$ gcc -o main main.C
$ gcc: error: spawn: No such file or directory
$ gcc -o main main.c
$ # all good
This only refers to the case of the extension as given to the gcc, the actual source file can have the extension in whatever case you want.
Explanation: This is from my experimenting with cygwin and gcc, I don't know the actual reason for this behavior.

error "missing separator" in build qwt-6.1

My environment:
QT: Qt_5_0_2
QWT: qwt-6.1-rc3
MinGW: mingw47_32
OS: win7_32
I follow the introduction file "INSTALL"'s step:
C) Win32/MinGW
Check that your Qt version has been built with MinGW - not with MSVC !
Start a Shell, where Qt4 is initialized. ( F.e. with
"Programs->Qt by Trolltech ...->Qt 4.x.x Command Prompt" ).
Check if you can execute "make" or something like "mingw32-make".
qmake qwt.pro
make
make install
I get the error in the step "make":
C:\qwt-6.1-rc3>qmake qwt.pro
C:\qwt-6.1-rc3>mingw32-make
cd src\ && ( if not exist Makefile E:\Qt\5.0.2\5.0.2\mingw47_32\bin\qmake.exe C:
\qwt-6.1-rc3\src\src.pro -o Makefile ) && mingw32-make -f Makefile
mingw32-make[1]: Entering directory 'C:/qwt-6.1-rc3/src'
mingw32-make -f Makefile.Release all
mingw32-make[2]: Entering directory 'C:/qwt-6.1-rc3/src'
Makefile.Release:305: *** missing separator. Stop.
mingw32-make[2]: Leaving directory 'C:/qwt-6.1-rc3/src'
Makefile:40: recipe for target 'release-all' failed
mingw32-make[1]: *** [release-all] Error 2
mingw32-make[1]: Leaving directory 'C:/qwt-6.1-rc3/src'
makefile:44: recipe for target 'sub-src-make_first-ordered' failed
mingw32-make: *** [sub-src-make_first-ordered] Error 2
The lines 304,305 in "Makefile.Release" are:
304 qmake: FORCE
305 #$(QMAKE) -o Makefile.Release src.pro
Where is wrong?
thanks
Makefile.Release:305: *** missing separator. Stop.
This usually means this Makefile is not of the right format for mingw32-make;
Since the Makefile is generated by qmake, you should check the QMAKESPEC of your qmake. It should be win32-g++, not win32-mvsc.
This issue is strongly linked to the first warning of the qwt INSTALL note :
Check that your Qt version has been built with MinGW - not with MSVC !
Guess your broken Makefile is leftover from some earlier attempts - remove the Qwt build directory completely and start from scratch.
For loading the Qwt designer plugin in the Qt creator you need to have a version that is compatible with how the creator had been built. AFAIR the 5.0.2 mingw package contains a version 2.7.0 of the creator, that had been built for Qt 4.8 with MSVC ( see About->Qt creator ). If true it means you need to have 2 different builds of Qwt - one for your application, the other one for the designer plugin.
For the future I'm planning to offer precompiled versions of the designer plugin that are compatible with current binary packages of the Qt creator.
Also note that in SVN trunk the default settings for building the plugin have been changed since rc3: on windows the library is statically linked into the plugin and on better systems you have a similar effect with compiling in the install path of the library ( see RPATH ).
I had the same problem. The reason was that I wanted to prepare sources second time. I had sources in svn floder. I solved proble erasing folder and update sources again. After this operation I was able to run 'qmake proj.pro' correctly.

generic makefile?

Is there a generic makefile i can use to build a simple c++ project? on windows?
i modified a working wii makefile to win32 but could not build properly (difference in make? the make app and the makefile seem to be found). I did a little hack and made a copy of mingw32-make as make.
-edit-
export PATH seem to be the reason i got my old error (make: make Command not found)
now using my new makefile (single file instead of 2) i get
"make"
make[1]: Nothing to be done for `/c/nightly/test/test.exe'.
this is my current makefile
http://pastie.org/318548
I am using mingw. I have a installation from that site along with another with codeblocks. the 'make' binary is a copied mingw32-make.exe where i chopped off the prefix. doing make -h i get "This program built for i686-pc-msys" so it looks correct
Your make file looks fine, for the most part.
Check to see that gcc and g++ are installed correctly.
Also the Clean target uses: rm -rf
rm is the unix (linux et al) command for remove. In order to get rm on windows, I recommend using Cygwin.
Which C++ compiler are you using?
As indicated in the error message, the problem does not come from your Makefile.
"make" itself couldn't be found in your path.

Resources