i'm trying to make fltk 1.3.x r9678 after using cmake to generate mingw makefiles. upon running make, windows version and copyright info are displayed instead of compiling fltk. i'm using the latest version of mingw
I just went through building FLTK 1.3.2 using MinGW and there was no need to create your own makefiles. Here are my notes with some comments in parenthesis:
Start Menu - All Programs - MinGW folder - MinGW shell (start MinGW
shell)
cd to fltk-1.3.2 (in the MinGW shell change directory to the root
folder of FLTK)
make clean (clean out previous bad build if any)
LDFLAGS="-static-libgcc -static-libstdc++" ./configure
--enable-threads --enable-localjpeg --enable-localpng --enable-localzlib (configure it to build for MinGW)
make
make install
Hope this helps others in the future.
Related
I downloaded:
https://mingw-w64.org/doku.php/download/mingw-builds
https://mingw-w64.org/doku.php/download/msys2
and installed them under C:/development/msys64. Under this folder I find the msys2.exe and the mingw64 folder, which in turn contains the bin one with all the mingw executable.
I added C:/development/msys64/mingw64/bin folder to the PATH env var.
In fact from a Windows prompt I can invoke the gcc - for example. Instead inside the msys2 shell I cannot find them. I mean, they are in /mingw64/bin but they are not available at prompt.
I'm sure I missed some steps!
Method to switch from MinGW-w32 to MinGW-w64
Download the executable file of MinGW-w64 Refer the EDIT
(Executable file link may change for future releases, this is for Version 8.1.0, Kindly cross verify the latest version before installing from this link)
Installation Process (In Settings):
Version: PICK LATEST
Architecture: x86_64
Threads: posix
Exception: seh
If anyone is trying to add MinGW-w64 as a PATH variable and is not able to find the gdb.exe in C:\msys64\mingw64\bin, try looking for it in the Program files.
C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin
The gdb.exe and other files are located in this directory.
EDIT:
After making some changes in the launch.json file in VSCode, the MinGW-w64 GDB debugger started giving errors because there was 2 versions of MinGW in different folders i.e, MINGW and mingw64!
It is essential that the installation path does not contain any spaces
(i.e., space in "Program Files"), this will create conflicts later.
STEPS:
1. Uninstalled all the versions of GCC that was installed in the PC - Cygwin, MSYS2(32 bit) and mingw64(64 bit) and installed the MinGW-w64 again, this time using the MSYS2.
Please start afresh, if debugger is giving errors and if versions are clashing!
2. Download the MSYS2 installer from this link.
Install process is simple, follow the steps mentioned in the website!
It is essential that the installation path does not contain any spaces. Therefore, we cannot install MinGW-w64 in Program Files.
3. After Installation is complete: Open MSYS2 terminal (pink icon).
Update the package database and base packages using:
pacman -Syu
After this, Update rest of the base packages using:
pacman -Su
4. Now switch over to MSYS2 MinGW 64-bit terminal (blue icon).
To install gcc and g++ for C and C++.
For 64 bit:
pacman -S mingw-w64-x86_64-gcc
To install debugger (gdb).
For 64 bit:
pacman -S mingw-w64-x86_64-gdb
5. Now you're all SET!
Check versions:
gcc --version
g++ --version
gdb --version
6. Finally, remove the old environment variables if any are left and add the new environment variable to the PATH!
BEFORE DEBUGGING FILES IN VSCode, MAKE SURE TO ADD -g tag while building, otherwise breakpoints will be ignored by the debugger!
Footnote:
It's very important to keep all the versions in one folder, if folders are different, then life will get tough later!
MSYS2 has packages for its own GCC toolchains and you would probably be better off using those toolchains instead of downloading a different one. For example, to use a 64-bit MinGW GCC, you would have to run pacman -S x86_64-w64-mingw32-toolchain and then make sure you are starting MSYS2 using the "MinGW-w64 64-bit Shell" shortcut (or something like that) so that /mingw64/bin is on your PATH.
Also, MSYS2 does not respect your system or user environment variables; it uses its own PATH by default.
I am using msys2 Mingw (gcc 4.8.2 for i686 32-bit) for building Ghostscript 9.10. After running make, gs.exe was created successfully. Followed by that I ran "make so" for creating libgs library. Libgs.so, Libgs.so.9.10 were created which are of the same file size. But I found both of them to be PE executables. After renaming extension to .exe, they produced the same output as done by gs.exe. What I require is libgs.dll, libgs.a to be created, but instead "make so" creates libgs.so which is in fact a PE executable. I also tried using patch found on site:https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-ghostscript/mingw-build.patch, but still the output remains the same. Has anyone been successful in this? Kindly help me.
I presume if you follow the steps taken in the build script connected to the patch you linked, everything will work out fine. I think most of it is just to make it use the "system"'s 3rd party libraries instead of those in the GS source. I'd guess running the configure command would do.
Alternatively, you could just download the MSYS2 base system from here, and do a pacman -Syu mingw-w64-i686-ghostscript. It should download and install the binary package without you having to build it yourself.
If you really want to build it yourself, download the PKGBUILD and patch, and run makepkg from the aforementioned MSYS2 shell and have that build it for you.
Have just completed testing of gs 9.15 built executables using the a patch
MINGW-packages-master.zip from https://github.com/Alexpux/MINGW-packages
Without implementing the zlib patch and PKGBUILD and using a MINGW 4.7.3 32/64
without by ghostscript used libs installed.
They did not work as is while using msys1 pathe'd up ahead of Windoze.
I simply edited the the MINGW Build and 32/64 bit type in makefile in
and set them to =1 there. and as i built without GTK defined in ./configure
SOC_LOADER_PLAIN manually to gs.c
Check the makefile after ./configure ahead of make or make so though , , .
All went well except for the COMPILE_INITS
mkromfs build that failed so I had to set that to =0 and build without that
feature. For me personally preferred as one can patch the gs fonts and libs
much easier.
The builds run as charm with full cpu optimisers implemented
only disabling gcse and guess-branch-probability, easily outperforming
the binaries provided by http://www.ghostscript.com/ by all means.
HPC !
the basic idea was, I wanted to generate the call graph in text format for several c files. After googling around for long time, i found cflow, which can deliver everything I want, but it is only runable in Linux or else. Then I began to search how to compile the cflow source files on the web to a exe file. I found MinGW which should be able to do the cross-platform compilation.
After installing the MinGW and the MSYS and running the usual commands "./configure; make; make install", I simply got an error that "mkdir" was not found. Actually. Actually I was wondering whether this is the correct way to compile the whole package.
Does anyone has an idea how I can build the cflow.exe correctly in Windows? If there is a tutorial or something like this, I will be very thankful.
Song
Solution
Please try this Github repository "MinGW + MSYS build of GNU cflow 1.4" (For Windows).
https://github.com/noahp/cflow-mingw
It contains already compiled "cflow.exe",and an instruction about how to build cflow using mingw and msys.
Test
System Environment:Win 8.1 (x64)
1.I tested the "cflow.exe" downloaded from the github repository , and amazingly it worked!
2.I followed the mingw compiling instruction,and it successfully compiled "cflow 1.5".
Command:
bash configure
make
I was able to do that today. I'm using cygwin, after installing gcc, binutils, make and after downloading the gnu cflow.tar.gz, it was as easy as ./configure ; make ; make install.
Running on Windows 7 with msys installed along with gcc and the source for GNU make 3.81.
In an msys bash shell I run ./confgure which enables both WINDOWS32 and HAVE_DOS_PATHS
Then running make produces an executable which reports 'This program built for i686-pc-mingw32'
If I then copy the resulting .exe into the /mozilla/build/msys/bin folder, make fails, claiming it cannot find files. The locally built version is ~2.3MB as compared to the ~153KB for the Mozilla version.
Can anyone tell me how the Mozilla crew builds their version of make for Windows?
Thanks.
Maybe you'll find the source to the mozillabuild package helpful.
From llvm.org I've downloaded llvm-2.6-x86-mingw32.tar.bz2 into c:\llvm and llvm-gcc-4.2-2.6-x86-mingw32-tar.bz2 into c:\llvm-gcc as well as setup a desktop shortcut the following batch file in c:\llvm-gcc which attempts to setup an environment for compiling via the llvm-gcc command line too:
#echo off
color 0E
echo Configuring LLVM environment...
set LLVM_LIB_SEARCH_PATH=%~dp0lib
set PATH=c:\llvm;%~dp0bin;%PATH%
Unfortunately, this setup gives the following error when trying to compile a simple hello world program:
C:\CDev\sandbox>llvm-gcc -o hello.exe hello.c
llvm-gcc: CreateProcess: No such file or directory
I've briefly looked through the LLVM binaries and it appears that the MinGW-based Win32 API and runtime files are already included. I also tried adding the MinGW DLL to c:\llvm-gcc\bin to no avail.
What have I missed in setting up the binary LLVM environment and GCC-based front end on Vista?
Thanks, Jon
Because the GNU/MinGW assembler 'as' was required by 'llvm-gcc' to generate the obj file. The problem can be solved by using:
Install GNU/MinGW binutils, extract the as.exe into c:\llvm-gcc\bin
Install a full MinGW package, add %MinGW%\bin your %PATH%
#rwallace is correct that one needs to also install MinGW's binutils along with the LLVM binary download. I've updated the LLVM documentation appropriately at
http://llvm.org/docs/GettingStarted.html#installcf
As far as I can tell, the answer is that the MinGW distribution supplied by LLVM is not complete, in particular, it doesn't come with the 'binutils' programs.
The recommended solution seems to be to download and install MinGW yourself. However, the MinGW download page seems to be saying this requires 10 different packages to be downloaded and installed separately.
The solution I tried today was to use the MinGW that comes with Qt, which does come in a single package; thus far, that appears to work.
It seems like it is looking for the base MinGW installation in C:\MinGW. I just had this error today using gcc.exe in msys. To solve it, I created a symbolic link from c:\msys to c:\MinGW and everything worked.