I was trying to build gdal-1.10.0
(http://trac.osgeo.org/gdal/wiki/DownloadSource) using mingw64 (from
http://sourceforge.net/projects/mingwbuilds/files/host-windows/
x64-4.8.0-release-posix-seh-rev2.7z). I have compiled gdal-1.10.0 under the
standard MinGW (32-bit) version without a problem.
The reason I have to switch to mingw64 is that the standard 32-bit MinGW distribution
does not support c++11 features like std::thread, and (I suspect) other features as
well. But I get an linking error in the end telling me something about
undefined reference to '__imp_GetACP'
(or a different decorated name if I use the 32-bit variant from
mingw64/mingw-builds). BTW, I tried different versions of mingw64, including
64-bit, 32-bit, seh, sjlj, but all gave the same error about GetACP().
I did some homework and found some instructions for a similar compilation task:
http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env
According to the above website, it seems that they suggest the problem has to do
with WOW64 and the correct version of windows dll files cannot be used because
windows automatically determines it for you depending on whether a 32-bit or
64-bit application making the call. This is supposedly a problem for mingw64
because the compiler gcc is 64-bit but msys is hopelessly 32-bit.
But since I tried 32-bit versions as well, the above does not seem to explain
the error.
Even more, I tried in a dirty way to comment out all calls to GetACP(),
because I don't really care about code pages and all that for my purposes.
Strangely enough, compilation is OK (on a fresh source just with the GetACP()'s commented out), but the same link error is still reported. I checked that libkernel32.a, libiconv.a are in the lib folder, and also followed the instructions in the blog above to copy dll's out from
c:\windows\system32 and place them in mingw subfolders with appropriate renaming. The link error remains. This is where I stopped hacking after spending almost two days on this without success. I can't understand why the entire source-code does not contain a single call to the function and I am still getting the link error.
Can anyone explain what might have caused this issue between gdal and mingw64,
and how to fix it?
Also, a general question about mingw64 is that is it really able to support
posix functions? I see package names such as
x64-4.8.0-release-posix-seh-rev2.7z, but I remember that the MinGW people said
they will never support full posix.
P.S.
I am testing this on a Windows Server 2008 R2, 64-bit.
Update:
The complete steps for building gdal-1.10.0 under MinGW64 (mingw-builds) are:
$./configure
Then,
Edit GDALmake.opt, Find GDAL_ROOT and replace the cygwin drive format with dos/mingw format, e.g.
Change:
GDAL_ROOT = /d/temp/build/gdal-1.10.0
to
GDAL_ROOT = d:/temp/build/gdal-1.10.0
Replace
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL)
with
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) -liconv
Finally,
$ make && make install && cp apps/*.exe /usr/local/bin/
I have accidentally encountered the same problem.
Maybe this is a MinGW bug or bad configuration files, but the solution is to add
-liconv to the end of linker flags, for example, replace
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL)
with
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) -liconv
in GDALmake.opt file (found by searching Mingw directory for GetACP in files).
Related
I just downloaded and installed Mingw. I also setup the system environment variables for C:\MinGW\bin and C:\MinGW\msys\1.0\bin. I wanted to test to see if I had installed it correctly (it seemed to be since running gcc --version worked), so I wrote hellow world in c and tried to compile with gcc main.c -o hello_world.exe. However I got the error:
"The code execution cannot proceed because libewinpthread-1.dll" was not found. Reinstalling the program may fix this problem."
I have tired reinstalling it and restarting my computer. I have also tried to see if this problem has occurred to others, and while there are a few places it is mentioned, I can't seem to find a solution mentioned. I have thought about trying to download the dll separately, but if I remember correctly, downloading dlls is a big no no.
Awhile ago I installed mingw though chocolatey and it seemed to be working. I have deleted that download from my computer and removed the paths, since I wanted to try to install it the normal way. Could this be part of the error?
Any ideas what the issue could be? Thanks!
You have built an .exe file that depends on libwinpthread-1.dll.
Solutions to make sure the .exe can run:
Add the MinGW bin path to your PATH so libwinpthread-1.dll - this would only fix it for your own system so I wouldn't recommend this if you want to use the .exe file on other systems.
Copy libwinpthread-1.dll from MinGW in the same folder as your .exe file. This is generally needed for any shared dependancy library your .exe is linked against.
Build a static .exe (--static linker flag) to avoid the shared (.dll) dependancy.
Yes! probably is an error, cause MinGW is a bit stinky when it comes to DLLs
Here are some things you have to check:
Make sure the variable helding the location of MinGW is named "path"
and its pointing at: C:\MinGW64\bin
I have a Windows 7 64bit system with the latest MinGW (32bit) installed along with the Qt 5.5 SDK (again 32bit) which also ships with its own MinGW. Due to the fact that I'm not the only one using the system I can't remove the standalone MinGW.
My project is using qmake and is a plain C project (not C++). Everything builds fine but when I try to execute my binary in the command line I get that the application was unable to start due to a missing libgcc_s_dw2-1.dll on the system.
After looking into the issue I found that both the standalone MinGW and the one shipped alongside the Qt SDK have the mentioned DLL.
Standalone MinGW - libgcc_s_dw2-1.dll is located inside the bin subdirectory of the MinGW installation where the binaries are located (gcc, g++, gdb etc.)
Qt MinGW - libgcc_s_dw2-1.dll is located inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\lib subdirectory while the MinGW components' binaries are inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\bin.
I would like to know how to properly set my PATH variable so that:
The application starts properly
No conflicts with the standalone MinGW installation occur
Just a side-note: I've already checked other posts here on SO but was unable to find a solution (perhaps I've missed it). I have also tried LIBS += -static but the result is the same.
You just need to copy this dll with your executable, i.e.:
cp <path-to-qt-install-dir>\qt5.7.0\5.7\mingw53_32\bin\libgcc_s_dw2-1.dll <path-to-dest-dir>
You mat find that you have other dependencies, to see which other deps you have you can use: ldd <your-executable>. You only need to copy the qt specific dlls you can see these by:
ldd <executable> | grep -i qt
note
You can statically link it with:
linker commands like -static-libgcc or -static, but I think you start to hit LGPL issues and also you may need to statically compile qt from source - can't recall for this particular file.
note2
Sorry ldd is for linux, just realized you have windows, in which case you can use one or both of:
dependency walker: from here
<path-to-qt-bin-folder>\windeployqt.exe <path-to-your-executable>
I have mixed results with windeployqt, but if you have any plugins its quiet good for getting that part sorted.
I'm trying to get started on using an ARM STM32F4 Discovery Board and I'm getting some weird compiling errors when using the "GNU Tools" on Windows 8
Currently my code is very simple:
#include "stm32f4xx_conf.h"
int main(void)
{}
This compiles using the "make" command perfectly find on Ubuntu 12 and windows 7, however I get the following error in Windows 8. I installed the same toolchain on all machines.
C:/Program Files (x86)/codesourcery/sourcery g++
lite/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/ld.exe:
error C:\Users\MyName\AppData\Local\Temp\cckUTM2f.o users VFP register
arguments, main.elf does not
I have narrowed down this error down to the flag "-mfloat-abi=hard", which when switched to "-mfloat-abi=soft", lets the code compile, however this conflicts other files that are previously compiled with "-mfloat-abi=hard".
Does anybody know why this would only occur on Windows 8 and how to fix it? If more information is needed, let me know. Sorry in advance if this is a nooby-question as I'm very new to this!
This answer may appear at the surface to be unrelated, but there is an indirect cause of this error message.
First, the "Uses VFP register..." error message is directly caused from mixing mfloat-abi=soft and mfloat-abi=hard options within your build. This setting must be consistent for all objects that are to be linked.
The indirect cause of this error may be due to the Eclipse editor getting confused by an error in the project's ".cproject" file. The Eclipse editor frequently reswizzles file links and sometimes it breaks itself when you make changes to your directory structures or file locations. This can also affect the path settings to your gcc compiler - for a subset of your project's files. While I'm not yet sure of exactly what causes this failure, replacing the .cproject file with a backup copy corrected this problem for me. In my case I noticed .java.null.pointer errors after adding an include directory path. I also found that a different path to the gcc compiler was being used for some of my sources that were local to the workspace, but not all of them. The two gcc compilers were using different float settings for unknown reasons - hence the VFP register error.
I compared the .cproject settings with a older copy and observed differences in entries for the sources causing the trouble - even though the overriding of project settings was disabled. By replacing the .cproject file with the old version the problem went away, and I'm leaving this as a reminder of what happened.
The solution was actually very simple, it was related to the PATH variable not being set correctly by the toolchain's installer. To solve it in windows 8, go to Environment Variables => System Variables and I added "C:\Program Files (x86)\GNU Tools ARM Embedded\4.8 2014q1\bin" to the path variable. The installer had put it under "User Variables for Name" and that, forever reason, didn't work.
I just installed Dev C++ and I am learning C programming.
the code i used was
#include <stdio.h>
int main()
{
printf("Hello world");
getch();
}
I saved it as a .c file. When I compile it works fine, but when I compile and run it says source file not compiled. So I googled buncha things and came across this video on youtube which shows you how to fix it. I also saw other forums on google which suggest the same thing... However, after doing whats asked, Now I can't even compile my code. I get this error
Compiler: Default compiler
Executing C:\Dev-Cpp\bin\gcc.exe...
C:\Dev-Cpp\bin\gcc.exe "C:\Users\ubaid\Documents\C\Untitled1.c" -o "C:\Users\ubaid\Documents\C\Untitled1.exe" -I"C:\Dev-Cpp\include" -L"C:\Dev-Cpp\lib"
gcc.exe: Internal error: Aborted (program collect2)
Please submit a full bug report.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
Execution terminated
I have also used what is asked on this link, and still no luck..
http://learntogeek.com/miscellaneous/solved-source-file-not-compiled-error-in-dev-cpp/
I am using windows 8
I was having this issue and fixed it by going to:
C:\Dev-Cpp\libexec\gcc\mingw32\3.4.2
, then deleting collect2.exe
Install new version of Dev c++. It works fine in Windows 8. It also supports 64 bit version.
Download link is http://sourceforge.net/projects/orwelldevcpp/ .
I guess you're using windows 7 with the Orwell Dev CPP
This version of Dev CPP is good for windows 8 only. However on Windows 7 you need the older version of it which is devcpp-4.9.9.2_setup.exe
Download it from the link and use it.
(Don't forget to uninstall any other version already installed on your pc)
Also note that the older version does not work with windows 8.
This maybe because the c compiler is designed to work in linux.I had this problem too and to fix it go to tools and select compiler options.In the box click on programs
Now you will see a tab with gcc and make and the respective path to it.Edit the gcc and make path to use mingw32-c++.exe and mingw32-make.exe respectively.Now it will work.
The reason was that you were using compilers built for linux.
You can always try doing it manually from the command prompt. Navigate to the path of the file and type:
gcc filename.c -o filename
I found a solution. Please follow the following steps:
Right Click the My comp. Icon
Click Advanced Setting.
CLick Environment Variable. On the top part of Environment Variable Click New
Set Variable name as: PATH then
Set Variable Value as: (" the location of g++ .exe" )
For ex. C:\Program Files (x86)\Dev-Cpp\MinGW64\bin
Click OK
This error occurred because your settings are not correct.
For example I receive
cannot open output file Project1.exe: Permission denied
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe: *** [Project1.exe] Error 1
Because I have no permission to write on my exe file.
After some investigation, and with Dr.Topaz's help, I have learned that you will want to confirm that the program set for g++ in the Compiler Options really does compile the source code. In my case, the C:\Dev-Cpp\bin\g++.exe program did not create an exe, but the C:\Dev-Cpp\bin\c++.exe program did. Either program appears to be intended to take the same arguments and options as GNU g++. I would love to find an actual doc on the Dev-C++ compiler programs, but I have not so far.
You can test the compiler program with a simple example like this:
C:\Dev-Cpp\bin\c++.exe hello.cpp -o hello.exe
Currently in 2021, the Dev-C++ site invites you to download either original Dev-C++ or a newer fork by a group named Embarcadero.
I decided to try the Embarcadero version and the experience was slightly better. The UI is still a tad dated, but the g++.exe program it came with was able to compile programs without issue. Again, take note of where the program is being installed, but in my case, the Embarcadero compiler programs were in C:\Program Files (x86)\Embarcadero\Dev-Cpp\TDM-GCC-64\bin.
Both original Dev-C++ and Embarcadero come with mingw-32 versions of the compiler programs that from what I see do work in a Git Bash console, with slight differences such as not recognizing a default locale when using the command std::cout.imbue(std::locale("")).
I faced this similar error, and none of the solutions worked.
so I tried to download the latest version from here, https://www.bloodshed.net/
I rerun the program.
and everything is now working correctly.
I was facing the same issue as described above.
It can be resolved by creating a new project and creating a new file in that project.
Save the file and then try to build and run.
Hope that helps. :)
I haven't done C in a long time. I'd like to compile this program, but I have no idea how to proceed. It seems like the makefile refers to GCC a lot and I've never used GCC.
I just want an executable that will run on windows.
You may need to install either cygwin or mingw, which are UNIX-like environments for Windows.
http://www.mingw.org/
http://www.cygwin.com/
When downloading/installing either cygwin or mingw, you will have the option of downloading and installing some optional features; you will need the following:
gcc (try version 2.x first, not 3.x)
binutils
GNU make (or gmake)
If it requires gcc and you want it to run on Windows, you could download Cygwin.
That's basically an emulator for GNU/Linux type stuff for Windows. It works with an emulation DLL.
http://www.cygwin.com/
In order to compile this program you need a C compiler. It does not have to be gcc, although you are already given a makefile set up to use gcc. The simplest thing for you to do would be the following:
Install cygwin
Open the cygwin command prompt
go into the directory where you have your makefile
type 'make'
That should compile your program
If you are not comfortable with using command line tools then you can download the free version of MS Visual Studio and import the source files into a new Visual Studio project. This way you would not need to install cygwin and use gcc, but you would need to know how to create projects and run programs in Visual Studio.
You almost certainly don't need all of cygwin to compile using gcc. There are plenty of standalone gcc clones for Windows, like gcw.
If it's reasonably portable C code (I haven't looked at it), then you may be able to just ignore the included Makefile and feed the source into whatever compiler you do want to use. What happens when you try that?
Dev-C++ provides a simple but nice IDE which uses the Mingw gcc compiler and provides Makefile support. Here are the steps I used to build the above code using Dev-C++ (i.e. this is a "how-to")
After downloading the source zip from NIST, I
downloaded and installed the Dev-C++ 5 beta 9 release
created a new empty project
added all the .c files from sts-2.0\src
Then under Project Options
added -lm in the Linker column under Parameters
added sts-2.0\include to the Include Directories in Directories
set the Executable and Object directories to the obj directory under the Build Options
and then hit OK to close the dialog. Go to Execute > Compile and let it whirl. A minute later, you can find the executable in the sts-2.0\obj directory.
First, there is little chance that a program with only makefiles will build with visual studio, if only because visual studio is not a good C compiler from a standard POV (the math functions in particular are very poorly supported on MS compilers). It may be possible, but it won't be easy, specially if you are not familiar with C. You should really stick to the makefiles instead of trying to import the code in your own IDE - this kind of scienfitic code is clearly meant to be compiled from the command line. It is a test suite, so trying things randomly is NOT a good idea.
You should use mingw + msys to install it: mingw will give you the compilers (gcc, etc...) and msys the shell for the make file to run correctly. Contrary to one other poster, I would advise you against using gcc 2 - I don't see any point in that. I routinely use gcc 3 (and even 4) on windows to build scientific code, it works well when the code is unix-like (which is the standard platform for this kind of code).