On a Windows system, currently I'm trying a waf configure on a directory of code, and it spits out the error "could not configure a C compiler."
Now, I'm 100% certain that I have gcc and g++ installed and in my path because when I type gcc --version, it gives me the current version information. (I'm using mingw and the gcc/g++ are in the /bin subdirectory).
In the author's code directory there is a wscript file which looks like
C_COMPILER = 'gcc-4.7'
CPLUSPLUS_COMPILER = 'g++-4.7'
Now, I have tried changing the strings to simply gcc as well as gcc-4.8.1 (since my current version is 4.8.1), but it still says could not configure compiler.
I tried reading one solution on this same site that looks related, but the solution was on ubuntu and trying to work through those commands didn't help
could not configure a c compiler
I'm at the end of my common sense here after making sure I have gcc and g++ installed, trying different strings in the wscript file trying to get it to recognize I have them installed, and could use some help, thanks.
Edit: I've now tried simply deleting the lines in the wscript file where it changes the compiler name, and suddenly waf configure goes through, but the waf build fails saying things like it can't find really basic things like include vector. The output says it's defaulting to msvs (microsoft visual studio) whereas the author says gcc/g++ is needed; maybe this is the issue but how do I get waf configure/build to use g++/gcc as default?
Related
So I get a bit confused on the many possibilities here. I have a CMakeLists.txt, which is hopefully all ready to be used. I am using WSL in the Windows Terminal and switching between microsofts cmd.exe and ubuntu wsl terminal on which I want to be able to run the compile command. So on which side do I need to run cmake and what build-files should I generate or what compiler should I use?
Main goal is having a simple compile cmd in vim on wsl, that compiles the exe for windows.
I tried to setup the build files with cmake from the wsl-side with the mingw cross-compiler, but during project setup it failed to find glfw3 configurations, which felt rather weird since it should use windows glfw files anways, right(?)
Next closest try was to create the build files with cmake from the cmd-site with the cl.exe compiler and ninja. That succeeded, but when now running ninja on the wsl side I get a lot of warnings concerning the unknown cmd option \O0 and fatal errors concerning not being able to include simple files like float.h, stdio.h, Windows.h etc. .
All my current search led me to this point, but I am not able to come up with a solution. So I would love to get some help. I want to stick mainly on the linux side, when programming but in the end have an executable for windows.
I am trying to compile "xz-5.2.1" in MinGW/MSYS environment. I see the following errors:
#error UINT32_C is not defined and unsigned int is not 32-bit.
error: #error size_t is not 32-bit or 64-bit
I am not familiar with MinGW, could anyone shed some light on this? It looks like some macro definition are missing. Some header file missing?
ADD 1
The commands I used to compile the xz-5.2.1 are:
./configure
./make
The error screenshot:
Some background, I am following this link to compile the Tesseract-OCR library. And this is just one of the steps.
ADD 2
Based on the error message, I checked the sysdefs.h file. It contains the following content:
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
The above make output contains the -DHAVE_CONFIG_H, so I think the system header file <config.h> should be included.
But strange enough, I searched the C:\MinGW\include, there's no such file. So I GUESS this may have caused the undefined UINT_MAX warning at line 57. And then the UINT32_C is not defined error at line 58.
But I don't know why the system header file config.h is missing and where to get it.
ADD 3
I dig a bit about the GNU autotools. And luckily enough I find that the following commands can carry on my build process: (Though I am still not very sure why it works. All I know is that it may be related to portability.)
autoheader (this generates the config.h.in file)
./Configure (this generates the config.h file from the config.h.in file)
And now, my build process is blocked by another issue as below:
It seems this is a known issue. And another thread has addressed it.
(I will continue update with my progress.)
If you care for an easier way to handle this kind of dependency management or a general update on toolchain functionality, I strongly suggest switching to MSYS2 with MinGW-w64.
Both projects aim (and succeed) in bringing a better version of the original. MSYS2 comes with a large number of 3rd party libraries that you can easily install. MinGW-w64 allows for GCC with full C++11/14/... support and extended Windows API availability, along with some useful extensions and more up to date headers. You'll notice that most problems originating from system headers will have already been solved, either by the MinGW-Packages scripts below, or upstream (of either MinGW-w64 or the projects themselves).
For you specifically, I suggest the following steps:
Install and update MSYS2.
Open an MSYS2 command prompt (or the 32-bit or 64-bit command prompts if you plan on building 32-bit or 64-bit things) from the start menu entries. Install {32-bit,64-bit} MinGW-w64 GCC:
pacman -S mingw-w64-{i686,x86_64}-gcc
Install tesseract-OCR:
pacman -S mingw-w64-{i686,x86_64}-tesseract-ocr
and optionally the data files:
pacman -S mingw-w64-tesseract-ocr-osd mingw-w64-{i686,x86_64}-tesseract-ocr-eng
And you're done. Of course, you can still compile the various dependencies yourself, but why bother? If you really want to, you can start from the build scripts for the packages you can install in MSYS2, which are located here:
https://github.com/Alexpux/MINGW-packages
Just open the PKGBUILD files and you can see the build steps required. Note that all these scripts assume the dependencies have been installed within MSYS2.
Also note that the installed packages and compilers are all independent of MSYS2 as you'd expect: you can use it only as a tool to keep your development tree up to date, and build from any other Windows environment.
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
i have made a program in vc++ 2010 in win7 but since the submission asked for a unix executable file i got ubuntu and am unable to compile to the program. i give the command:
gcc (filename) -o (submission file)
and i am getting a lot of errors as someone guided me over this site that vc++ code will be entirely supported in ubuntu. Then why is the problem? what is the solution?
also if any ide is needed can i use mu code block of windows for ubuntu as well?
You should be using g++ instead of gcc, also VC++ code may or may not work depending on what the submission is required to do as Windows has different libraries for certain things. Try using g++ instead and edit your errors into the question so we can help better.
I've been learning C++ and Allegro using Code::Blocks on Windows XP, and recently felt like learning Vim. However, I have no idea how to compile a program "manually" (i.e., without using an IDE).
For compiling from within Vim, I have gotten as far as setting the makeprg to gcc, but I understand I also need a makefile. What is that and how do I write one? Is it with the makefile that I can use libraries such as Allegro?
Also, I've gotten quite fond of the CB debugger (I'm using gdb). Is it possible to do something similar with Vim?
Thank you.
Look at MinGW. I would avoid Cygwin if you only need gcc and make. You'll want both MinGW and MSYS. MSYS has a windows port of make.
If you're interested in more unix utlities for the windows command line I recommend CoreUtils.
For learning make see the manual
You don't necessarily need a Makefile, but it's the preferred (and possibly sanest) way of compiling code on UNIX-like systems.
I don't know if GNU Make has a Windows port, but you can probably run it under Cygwin.
To learn more about GNU Make and Makefiles:
make (Wikipedia)
GNU Make
GNU Make Manual
Also, see this question: compile directly from vim
Mandatory edit: I don't use Windows or Cygwin. You might want to take epochwolf's advice on that department.
I'm not in expert in makefiles and debugging but I know that Vim lets you do many things.
For example if you want to compile a file with gcc, it's not very different from the usual way. In normal mode type:
:!gcc file.c -o file
In fact you can use (almost) every system command just by adding "!" in front of your command.
gdb also works with Vim
:!gdb
I hope it will help you.
To integrate vim with devenv, you can use devenv from Visual Studio to complie the project in vim. The command as follows:
Devenv SolutionName /build SolnConfigName [/project ProjName [/projectconfig ProjConfigName]]
Typicatlly, the devenv should located in C:\Program Files\Microsoft Visual Studio 8\Common7\IDE. Set it to the path of environment to make it callable from vim. We also need to make vim recognize the error messages thrown by the commandline build tool devenv. Just put the following lines in your vimrc:
" Quickfix mode: command line devenv error format
au FileType cpp set makeprg=devenv.com\ /Build\ Debug\ *[SolutionName]*
au FileType cpp set errorformat=\ %#%f(%l)\ :\ %#%t%[A-z]%#\ %m
Then You can use :make to compile and build the program from vim.
EDIT1: A few bookmarks you might find useful:
GNU make tutorial (this one uses gcc and make, so it should be right up your alley)
Another one
Win port of some of GNU utils Can was mentioning; I personally use these and haven't had any problems with them on Windows platform.
Yes, you can compile without the makefile. If your program is simple (for example, one file only) you can compile by calling the compiler and including the name of the program in the same line (don't remember how it goes with gcc). Of course, to make things easier this can be mapped to a key within vim, so you don't have to jump to command prompt and back.
If you are working on a bigger project, which consists of several files and such, than a makefile is useful. It will "search" through the files, determine dependencies, include them in the build, maybe put the source files in one directory and the resulting exe file in the other and such. So it is more of a linking and building system than just compiling.
Although the GNU make mentioned in Can Berk Guder's answer is a popular one, there are quite a number of other tooks for "building makefiles" ("makefile" has become a type of synonym for that kind of operation) - here, you can see some other options on this link. Due to its part in history vim has good support for :make, but others can be easily used as well (there are a lot of texts on this subject on VimWikia.
Well, that's it. Just my 0,2 euros :)
As long as you have GNU-make installed (with cygwin or mingw under windows), you don't need to write a makefile for single-file projects. Just run :make from vim, and that's enough.
If your project is made of several files, then you will have to write a makefile (or any equivalent for scons, aap, (b)jam, ant, ...), tune your &makeprg in consequence, and finally call :make from vim. See the relevant category in vimtips. You can of course run the compiler as you would have ran any other external tool, but you would loose the possibility to jump to the line(s) of the error(s).
NB: if you are using the win32 version of vim, and gcc-cygwin, you'll need to translate the error messages obtained. I used to maintain a perl script for this purpose, it is now part of a bigger suite (still in beta stage)
Regarding your question about debugging, it can't be done from vim under windows for the moment. The only debugger that can be integrated so far is gdb, but under linux only ; see the pyclewn (.sf.net) project.
I'm not sure about debugging, but I know an easy way to compile and run the current program as I wrote a small vim plugin to do so.
http://pastebin.com/qc5Zp2P7
It assumes you are using the g++ compiler. If not, just change the name to the compiler you're using. Save this file to whereveryouinstalledvim/ftplugin/cpp.vim
In order to compile and run the currently open program, just type shift-e while in non-editing mode.