I've just build a gcc 5.2.0 on windows according to this material:
http://preshing.com/20141108/how-to-install-the-latest-gcc-on-windows/
Everything went well. But then I've tried to build Qt with this newly built gcc and I'm getting an error that there is no mingw32-make. Checked directory and no, there isn't one.
But then I checked previously installed gcc, which was work of TDM, downloaded from:
http://tdm-gcc.tdragon.net/
and yes, in his build there is mingw32-make.
So, the question is, how is it that he has that tool, and many other which are absent in my build are present in his?
if you create from the gcc5.2.0 source, a build then you've just created the gcc compiler with all its necessary files. e.g. gcc-5.2.0.exe, gcc.exe, g++.exe, etc.
NOT the MinGW runtime environment for gcc, which contains the mingw32-make.exe !
if you follow your link from your question here you build it with the cygwin make.exe.
It's better to download the mingw 32 binary runtime environment for gcc
or
MinGW64 runtime environment for gcc
Then you have all the files needed to work with QT.
if you want to create a mingw build from source, you need first a MinGW runtime environment then you can use that to build your own mingw32-make.exe.
Related
How does one build GDB (the GNU Debugger) from source on Windows? I need to build it in order to make a build with Python support. I cannot use the one distributed with Cygwin because it has problems interpreting backslashes on Windows. What toolchains do I need for the build -- GnuWin32, MinGW, etc.? Can someone please provide step-by-step instructions on how to do this?
install (https://sourceforge.net/downloads/mingw) and configure MinGW with packages g++ gcc libc6-dev libtool pkg-config
get gdb sources (I use 7.latest from https://www.gnu.org/software/gdb/) and put it into MinGW/msys/1.0 folder
run ./configure in msys shell (MinGW\msys\1.0\msys.bat)
run make and fix the following:
hypot compile error with help of this '::hypot' has not been declared
undefined constants for GetLastError function by adding #include <winerror.h> into \gdb\gdbserver\win32-i386-low.c \gdb\gdbserver\win32-low.c gdb\ser-mingw.c
I have checked build process using 7.11.1 and 7.12.1 sources
7.12.1 x32 is broken under windows
https://github.com/Alexpux/MINGW-packages/issues/1909
https://sourceforge.net/p/mingw-w64/bugs/576/
I recently installed MSYS2 on Windows, along with the MinGW-w64 toolchain and CMake. Specifically, I used the following packages:
mingw-w64-i686-gcc
mingw-w64-i686-cmake
make
Trouble is, whenever I invoke CMake from within the MSYS2 shell with cmake -G"MSYS Makefiles", it fails with the following:
target_compile_features no known features for CXX compiler
"GNU"
version 4.9.2.
The line in CMakeLists.txt that generates the error is this: target_compile_features(myproject PUBLIC cxx_decltype).
If I run CMake from outside the MSYS2 shell (I also have it installed separately) with the "MinGW Makefiles" generator, the makefile generation succeeds.
Inside MSYS2, the CMake version is 3.2.3. The version outside is 3.3.0.
Is there any way to resolve this issue? Thanks in advance.
There was bug about interaction of compile features mechanism in CMake 3.3 with gcc 4.8+:
https://public.kitware.com/Bug/view.php?id=15443. It have been fixed several months ago. You need that fix being applied.
Run cmake from mingw64_shell.bat or mingw32_shell.bat. CMake will otherwise pickup msys2 GCC rather than a native one.
I'm trying to compile Pyaudio, (a Python module) from source, since I'm using Windows, and only 32-bit binaries are available - I need 64. Following these instructions I downloaded Cygwin, and installed every component, to be safe. Installing Portaudio, another module, is required first.
When I run CFLAGS="-mno-cygwin" LDFLAGS="-mno-cygwin" ./configure, I get the error configure: error: C compiler cannot create executables. See 'config.log' for more details. config.log has an additional line below that message: gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.
This leads me to believe that perhaps Cygwin is using the wrong compiler; the instructions are for using MinGw with Cygwin, but I never specified minigw in the process. I also wonder if there's something in the PyAudio build files that needs to be changed for 64-bit. I know nothing about C, compiling, Cygwin or MinGW, and am new to programming in general. Any ideas? Any other information I can provide?
Current versions of Cygwin gcc do not support -mno-cygwin anymore because it never really worked correctly. Instead, you should use a proper cross-compiler, which is provided by the mingw64-i686-gcc packages, then run ./configure --host=i686-w64-mingw32.
In some cases it is an antivirus that is causing problems.
I had avast and had to disable it.
I want to compile a source code, but there are some compiling errors about __sync_xxx functions (__sync_bool_compare_and_swap etc.)
GCC version on machine is 3.4.3 (it must be gcc 4.1 or over for supporting atomic builtins), so I have downloaded GCC v4.6, copied it to another directory (I didn't remove v3.4.3) then change the $PATH path for GCC but it doesn't work (the same error occurs).
I want to ask that is only changing gcc path with export PATH=... enough for compiling with new GCC?
Use the following configure option when compiling gcc:
--program-prefix=foo --program-suffix=bar
and it will produce bin programs of the form "foo-gcc-bar", so that you may differentiate different builds of gcc.
Replace foo and/or bar with an appropriate "tag" for your build (eg "-4.6" for example).
This way if it doesn't find your toolchain correctly it will fail fast rather than using the 3.4 version.
It also means that different toolchain builds can coexist in the standard installation prefix directories.
We have to use -march=686 switch to get it to work on intel.
Try checking and updating LD_LIBRARY_PATH, to use the lib path for the new gcc installed.
So I just downloaded mingw-w64-bin_i686-mingw_20110410.zip from here (GCC 4.7 apparently), and discovered it had a very recent version of the GCJ compiler.
I tried using it, but apparently gcj requires ecj1.exe, which is the Eclipse compiler for Java... so, where do I find a compatible version of the binaries of ECJ and the associated Java libraries that are needed (libgcj, etc.)?
Ideally this would be found on the MinGW-w64 project page, but it doesn't seem to exist.
(I've already tried copying them from a slightly older GCC version; it doesn't work.)
The cause for an openSUSE version of the gcc is basically this:
If the configure step of the compilation of gcc did not find the ecj.jar
file, ecj1 will be missing at the time when gcj, which has just been build,
is called.
ecj.jar can be taken from ftp://sourceware.org/pub/java/ecj-4.8.jar
for example.
The two options are:
i) Put ecj.jar in $HOME/share/java/ecj.jar, reconfigure gcc with
./configure .... --with-ecj-jar=$HOME/java/ecj.jar
and recompile gcc. Future compilations with that gcc will not require
ecj1 .
ii) Put ecj.jar in $HOME/share/java/ecj.jar and create ecj1(.exe)
through a compilation like
gcj -o$HOME/bin/ecj1(.exe) --main=org.eclipse.jdt.internal.compiler.batch.GCCMain $HOME/share/java/ecj.jar
assuming that the $HOME/bin is in the PATH for subsequent calls of gcj.
The thing that is actually "broken" here the fact that gcc 4.8.* is not shipped
by default with ecj.jar at some standard place.
That is a very old version of a MinGW-w64 toolchain.
I would suggest downloading one of my builds, I've had reports of gcj working (without libgcj, which does not work on Windows), although I can't seem to find a link to the discussion I had long ago with a user. The user's case had something to do with creating a JNI interface or something, which didn't require libgcj.
My old builds can be found here for 32-bit and here for 64-bit. I checked the 4.8 release build, and it contains the gcj compiler.
Would you be opposed to downloading the source and building it? I looked over the build doc in basic and advanced build docs. I didn't see anything about the GCJ compiler or ECJ, but you'll need gcc 4.5.1 in order to build it.