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.
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'm trying to work with a program that a physicist wrote. I'm on a MacOS, and I've downloaded all the programs and libraries that I was told was necessary for the program to compile and run (GCC, MPI, using the version of MAKE that is already on Macs). I opened the makefile, and I was told to write
F90 = mpif90
and then compile the program using
make IO=txt
but I get this message:
mpif90 -g -O3 -c mod_input.f90
make: mpif90: No such file or directory
make: *** [mod_input.o] Error 1
I have no idea what this means, and what to do to get this to work.
Take a look here:
http://www.owsiak.org/?p=3492
This article describes how to get, install and configure MPI (Open MPI flavor) at macOS. After installing it, you should get mpif90 as well.
I am trying to compile a program which uses GSL, in fact I am already able to compile it successfully on my local machine using
g++ -o program program.c prog0.o -L/usr/local/lib -lgsl -lgslcblas -lm
My problem is that I need to compile this program on a work machine in a shared system, but I know the program will not compile with an up to date version of GSL, so I need to install and use an older version.
I did this on my own system using the default installation, so the relevant files are located in /usr/local/lib on my local machine, and the compilation works for me with the above command.
But since the work machine is in a shared system, I cannot mess with the default directories, so I installed the correct GSL version on the work machine in my directory under /home/myname/gsl/.
So on the work machine the folder /home/myname/gsl/lib contains the same relevant files as the folder /usr/local/lib on my machine.
Now I did various attempts to try and tell g++ to use this custom installation folder, which I thought would come down to
g++ -o program program.c prog0.o -L/home/myname/gsl/lib -lgsl -lgslcblas -lm
but no success. No matter what I did g++ always used the GSL version installed on the shared system, even using just
g++ -o program program.c prog0.o
I only started programming C/C++ not long ago and only know the very basics of how to compile programs, so this linking thing is still always confusing me..
But as far as I can tell -L/dir/ should tell g++ to use the library in /dir/ and -lgsl -lgslcblas are the files which it should look for in that library... ?
But it seems g++ doesn't care what library I tell it here, it always seems to use whatever is in the PATH of the shared work system, which seems to include this up-to-date version of GSL that I cannot use. But I also cannot change the PATH since I only have access to my own subdirectories on the work system..
So how do I tell g++ to ignore the default version of GSL and use the one I installed manually at /home/myname/gsl/ ?
I figured out the answer, it is actually simple. The problem was just my lack of understanding proper usage of outside libraries and trying to fix the compilation command was the wrong approach.
In the code in program.c, gsl was included with
#include <gsl/gsl_blas.h>
and so on. Of course, the "<>" directly tell the compiler to look in known include directories, where the up-to-date GSL is installed on the shared system.. So the way to use a custom version was just to instead use
#include "/home/myname/gsl/lib/gsl_blas.h"
and so on, directly specifying that I want to use my custom installation.
I then compiled with
g++ -o program program.c prog0.o /home/myname/gsl/lib/libgsl.so /home/myname/gsl/lib/libgslcblas.so -lm
and it compiles successfully.
(This brought up some other unclarities for me, but at least this specific problem is solved.)
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
While I am sure that gcc libraries (.a) are incompatible with mingw lubraries (also .a), I want to know. Can I cross-compile a windows executable with mingw using the gcc .a library generated for unix systems?
In code form, keep in mind this is a unix system:
cd mylibrarydirectory/
make #produces mylibrary.a
cd ../myprogramdirectory/
gcc -o UnixExecutable mysrc.c -L../mylibrary.a
#and I get a valid unix executable
i586-mingw32msvc-gcc -o Win32Executable.exe mysrc.c -L../mylibrary.a
#will I get a valid windows executable?
No. You have to recompile the library for Windows.
The second command should give an "incompatible library format" or something error. Or at least undefined references to whatever is linked in.