I am trying to run makefile on windows7. I have added make.exe in windows path variable and
I am trying to run "make -f makefile.txt" but it shows error
"cc -o edit main.o kbd.o command.o display.o insert.o search.o files.o utils.o
process_begin: CreateProcess(NULL, cc -o edit main.o kbd.o command.o display.o i
nsert.o search.o files.o utils.o, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [edit] Error"
Please help me as i am new to make concept.
It is not sufficient to just add make.exe to the path. Your problem is that cc can not be found while trying to make the target called edit. Try running the same command from an MinGW/MSYS or CygWin shell, depending on how you installed this. That will most likely give you the proper environment to use make with this makefile.
This issue is similar to copy a file using a makefile at runtime
To make it work install MinGW (mingw-get-setup.exe) which will install mingw-get.exe utility that could be used to install all needed build tools.
With C:\Mingw\bin (or whatever path selected during installation) on $PATH type in console:
$ mingw-get.exe gcc g++ msys-base
After it finishes MSYS env will be available with all necessary tools (execute C:\MinGW\msys\1.0\msys.bat to open it)
Now you can use make like in unix envs.
Mike#Mike-PC ~
$ make
make: *** No targets specified and no makefile found. Stop.
If it is not enough install mingw32-make as well with mingw-get.
For some things on windows you'll want to install coreutils. I had this issue for nordic nrf micro issues with make but it's the same error
http://gnuwin32.sourceforge.net/packages/coreutils.htm
Landed here on a re-install of windows scratching head. This was the fix as it adds a bunch of useful commands to windows. Like why did "ls" work on my old drive and not the new one... answer core-utils. Why does it build everywhere and not here -- core-utils. Hope this helps someone in another 8 years.
Related
I'm following this tutorial to begin with Code::Blocks using wxWidgets.
Following the tutorial, my first step was:
cd C:\wxWidgets-3.0.3\build\msw
Since I have the mingw32-make.exe installed in the directory C:\Program Files\CodeBlocks\MinGW\bin, next I do the following (again based on the tutorial):
C:\wxWidgets-3.0.3\build\msw>"C:\Program Files\CodeBlocks\MinGW\bin\mingw32-make" -f makefile.gcc BUILD=release SHARED=0 MONOLITHIC=1 UNICODE=1 CXXFLAGS=-fno-keep-inline-dllexport
The output I get is:
gcc -c -o gcc_mswu\wxregex_regcomp.o -O2 -mthreads -DHAVE_W32API_H -DNDEBUG -I
..\..\include -I..\..\lib\gcc_lib\mswu -D__WXMSW__ -D_UNICODE -MTgcc_mswu\wxr
egex_regcomp.o -MFgcc_mswu\wxregex_regcomp.o.d -MD -MP ../../src/regex/regcomp.c
gcc: error: CreateProcess: No such file or directory
makefile.gcc:5702: recipe for target 'gcc_mswu\wxregex_regcomp.o' failed
mingw32-make: *** [gcc_mswu\wxregex_regcomp.o] Error 1
I think that gcc is not found, so I need to edit the makefile.gcc
Am I right?
I'm not used to makefiles, so, I apologize but I need some help.
Open a command box and cd C:\wxWidgets-3.0.3\build\msw
Type and press enter:
PATH=%PATH%;C:\Program Files\CodeBlocks\MinGW\bin
This will add the mingw needed files (they execute chained) to your PATH, only for the command box. If you want it permanent, modify PATHenviroment var in you Windows settings.
Now run the command to compile wxWidgets:
mingw32-make" -f makefile.gcc BUILD=release SHARED=0 MONOLITHIC=1 UNICODE=1 CXXFLAGS="-std=gnu++11" The std=gnu+11 flag is default (not needed) if your mingw version uses gcc >=5.2. Use it anyhow, it's harmless.
Adding RUNTIME_LIBS=static may avoid to have a couple of mingw libs visible (on the path). This way you can run your app without providing those libs.
Probably you'll get zillions of warnings (not errors) about "deprecating" with BestSize. That's a gcc <5.3 bug, not wx one.
You can get rid of those messages modifying a few lines at include/wx/window.h But better don't use the old version that ships with CB and download the newest one from http://www.mingw.org/
I am looking for a library for working with JPEG-XR images and imagemagick refers me to jxrlib provided by Microsoft.
There are no pre-built binaries. The source code comes with a make file, but when I try to build it using GnuMake, I run into errors saying that a .o file was not found.
cc -I. -Icommon/include -Iimage/sys -D__ANSI__ -DDISABLE_PERF_MEASUREMENT -w -O
-Ijxrgluelib -c jxrgluelib/JXRGlue.c
process_begin: CreateProcess(NULL, cc -I. -Icommon/include -Iimage/sys -D__ANSI_
_ -DDISABLE_PERF_MEASUREMENT -w -O -Ijxrgluelib -c jxrgluelib/JXRGlue.c, ...) fa
iled.
make (e=2): The system cannot find the file specified.
make: *** [JXRGlue.o] Error 2
How do I compile this on Windows?
If you happen to have Visual Studio installed, just open the included solution files and build. That has always worked for me. I can't say anything regarding other toolchains under Windows, but I know that it also builds successfully with make and gcc under Ubuntu.
If you can't get it to compile I can share binaries if that helps you.
Visual Studio project files have been added to jxrlib project. See Add vc14 project and solution files commit in the official repository at https://jxrlib.codeplex.com
Alternatively, use CMake configuration proposed here in Patch for warnigns + CMake for building.
So I have installed / compiled speech_tools, and Festival (2.3) using Cygwin on my Win8.1 machine to the point that I can successfully produce speech using this command:
echo "hello world" | \src\main\festival --tts
The next step is for me to get FestVox running. I have downloaded FestVox 2.6 and I have run ./configure; however, the 'make' step is giving me trouble, producing this error:
gcc -O3 -Wall -o phonealign phonealign_main.o -LC:/cygwin64/Festival/build
/speech_tools/lib -lestools -lestbase -leststring -lncurses -lstdc++ -lm -lwinmm -luser32
/usr/bin/ld: cannot find -leststring
collect2: error: ld returned 1 exit status
Makefile:80: recipe for target 'phonealign' failed
So, I looked at my Makefile at where it might be trying to look for this file, and it looks like in that directory (build\speech_tools\lib) I am missing a libeststring.a partner for my libeststring.lib. Both libestbase and libestools have .lib and .a files in that directory.
At what step did I go wrong?? Should a libeststring.a have been created at some point??? When? How can I fix this?
I think the problem is that you should use compiler in Windows instead of gcc within Cygwin. The role in Cygwin for building Festival is to run configure to generate a Makefile for VC. Then run nmake in Windows command line not make within Cygwin.
Cygwin cannot build a native Windows application like what MINGW does. Application build in Cygwin can only run within Cygwin.
*.a is the static library for Linux, which is built by gcc. *.lib is the static library for Windows, which is built by VC.
So I suggest you taking a look at README, INSTALL files in FestVox. To find whether there is description for make a Makefile for Windows like process "3. Make makefile for VC in Cygwin" in my document (http://www.eguidedog.net/doc_build_win_festival.php)
Cameron
I'm currently trying to compile redland (librdf http://librdf.org/) under Windows. According to their website it should build under Windows. As i don't want to spend my time fixing the .sln I thought about compiling librdf (and the necessary projects) in cygwin and then use the library in visual studio.
So my question is:
Is it possible to use librarys compile in cygwin in windows application? And if so how?
As I am a windows developer I don't know if there is any difference from the created .a files to .dlls. I already read up to the topic and it will be necessary to include the cygwin1.dll in the project but this won't be a problem.
Or does anyone have any better idea how I can get redland compiled as windows dlls?
I thought about using mingw but until now I didn't manage to compile it.
Any help will be appreciated.
Thanks
Update:
Thanks to the help of Yaakov (And his pretty cool cygwin ports) I meanwhile managed to compile raptor (which is a prerequisite for librdf).
All I had to do was include another argument for configure: --with-xml2-config=/usr/x86_64-w64-mingw32/sys-root/mingw/bin/xml2-config
Now I'm trying to compile rasqal which is another requesite and is also depending on raptor2.
For it to work I had to export PKG_CONFIG_PATH="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/" for pkg-config to find the correct raptor installation.
So configure for rasqal worked but when I try to make it I get the following error:
Making all in src
make[1]: Entering directory `/home/Stefan/workspace/rasqal/src'
make all-am
make[2]: Entering directory `/home/Stefan/workspace/rasqal/src'
/bin/sh ../libtool --tag=CC --mode=compile x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -DRASQAL_INTERNAL=1 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/raptor2 -g -O2 -DMTWIST_CONFIG -I../libmtwist -g -O2 -MT rasqal_algebra.lo -MD -MP -MF .deps/rasqal_algebra.Tpo -c -o rasqal_algebra.lo rasqal_algebra.c
libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -DRASQAL_INTERNAL=1 -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/raptor2 -g -O2 -DMTWIST_CONFIG -I../libmtwist -g -O2 -MT rasqal_algebra.lo -MD -MP -MF .deps/rasqal_algebra.Tpo -c rasqal_algebra.c -DDLL_EXPORT -DPIC -o .libs/rasqal_algebra.o
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/sys/time.h:10:0,
from rasqal.h:116,
from rasqal_algebra.c:39:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/time.h:260:8: error: redefinition of 'struct timezone'
./win32_rasqal_config.h:62:8: note: originally defined here
Makefile:1045: recipe for target `rasqal_algebra.lo' failed
make[2]: *** [rasqal_algebra.lo] Error 1
make[2]: Leaving directory `/home/Stefan/workspace/rasqal/src'
Makefile:720: recipe for target `all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/Stefan/workspace/rasqal/src'
Makefile:484: recipe for target `all-recursive' failed
make: *** [all-recursive] Error 1
Which I can't get my head around I'm not really into cross compiling.
Can someone point me into the right direction?
The MSVC and Cygwin runtimes are incompatible, so you cannot use a Cygwin-compiled binary within VS. However, you can use Cygwin to cross-compile a library for Windows, which for C libraries, should be compatible with VS. (C++ is very compiler-specific, particularly with symbol mangling, but IIRC these libraries are all in C.)
To get started, you need to install the mingw64-i686-gcc-core, mingw64-i686-headers, and mingw64-i686-runtime packages, plus all dependencies, via Cygwin's setup.exe installer. Then, beginning with the "bottom" of the dependency chain, build each library with e.g.:
./configure --prefix=/usr/i686-w64-mingw32/sys-root/mingw --host=i686-w64-mingw32
Then run make followed by make install. For Windows x64, substitute all the i686s above with x86_64.
Keep in mind that librdf has a lot of (sub)dependencies, but I don't remember now how many are optional. Some, but not all, of these are available from the Cygwin Ports repository; those should at least help you get started.
I recommend you to build raptor2 using Visual Studio.
I did this successfully for Visual Studio 2017 x64 this way:
Install libxml2 and libxslt
Open PowerShell:
git clone https://github.com/Microsoft/vcpkg
cd vcpkg
.\bootstrap-vcpkg.bat
.\vcpkg install libxml2:x64-windows
.\vcpkg install libxslt:x64-windows
Build raptor2
Download raptor: http://librdf.org/raptor/ (http://download.librdf.org/source/raptor2-2.0.15.tar.gz)
Change raptor2-2.015/CMakeLists.txt, line 258:
ADD_DEFINITIONS(-DHAVE_CONFIG_H)
->
ADD_DEFINITIONS(-DHAVE_CONFIG_H -DYY_NO_UNISTD_H)
change raptor2-2.015/src/CMakeLists.txt, line 118:
ADD_LIBRARY(raptor2
raptor_avltree.c
...
->
ADD_LIBRARY(raptor2
raptor_escaped.c
sort_r.c
raptor_ntriples.c
raptor_avltree.c
...
open cmake:
set LIBXML2_INCLUDE_DIR to: path/to/vcpkg/installed/x64-windows/include
set LIBXML2_LIBRARIES to: path/to/vcpkg/installed/x64-windows/lib/libxml2.lib
set LIBXSLT_INCLUDE_DIR to: path/to/vcpkg/installed/x64-windows/include
set LIBXSLT_LIBRARIES to: path/to/vcpkg/installed/x64-windows/lib/libxlst.lib
set LIBXSLT_EXSLT_LIBRARY to: path/to/vcpkg/installed/x64-windows/lib/libexlst.lib
Deployment:
Set CMAKE_INSTALL_PREFIX to your deplyoment path e.g. C:\thirdparty\vs2017\x64\raptor2
Execute the INSTALL target in Visual Studio.
If you do not like to execute this steps manually you can just download a prebuild version here.
I am trying to compile a project that required freetype library so I was figuring out how to install freetype to mingw32 and the more safer way is to compile it.
Anyway the problem was compiling freetype-2.4.11
I went into bash provided in msys
I did ./configure within freetype's main dir and everything looks fine
next I did mingw32-make which created the problem
libtool: compile: gcc -pedantic -ansi -Ig:/Downloads/freetype-2.4.11/objs -I./b
uilds/unix -Ig:/Downloads/freetype-2.4.11/include -c -Wall -g -O2 "-DFT_CONFIG_C
ONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" g
:/Downloads/freetype-2.4.11/src/base/ftsystem.c -DDLL_EXPORT -DPIC -o g:/Downlo
ads/freetype-2.4.11/objs/.libs/ftsystem.o
Assembler messages:
Fatal error: can't create g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o: No
such file or directory
g:/Downloads/freetype-2.4.11/builds/freetype.mk:198: recipe for target 'g:/Downl
oads/freetype-2.4.11/objs/ftsystem.lo' failed
mingw32-make[4]: *** [g:/Downloads/freetype-2.4.11/objs/ftsystem.lo] Error 1
g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o seemed like it is trying to use a directory that is illegal in windows.
Thanks in advance
Try to use make instead (i.e. the one from MSYS distribution), and avoid using mingw32-make (from MinGW distribution) in the future to save yourself time and nerves. Extract from MinGW Wiki:
What's the difference between make and mingw32-make?
The "native" (i.e.: MSVCRT dependent) port of make is lacking in some functionality and has modified functionality due to the lack of POSIX on Win32. There also exists a version of make in the MSYS distribution that is dependent on the MSYS runtime. This port operates more as make was intended to operate and gives less headaches during execution. Based on this, the MinGW developers/maintainers/packagers decided it would be best to rename the native version so that both the "native" version and the MSYS version could be present at the same time without file name collision.