Go to the GMP download page. Download the archive of the latest release, a ".tar.bz2" or ".tar.gz" file - which one is irrelevant.
Extract this archive to a folder like "c:\c++\gmp" or something - try to avoid spaces and capital letters. To do this, you need a good archive program - if you haven't got one that can read the file (i.e. you double-click on it and it says "Windows cannot open this file"), download and install 7-Zip (from here).
Check that you have a folder like "C:\c++\gmp\gmp-4.2.1", or equivalent. This folder should contain several source files and folders.
Assuming you have MinGW installed (it comes with Dev-C++), you only now need MSYS to run the "configure" script. To install this, go to the general release section of MinGW on SourceForge, click on "MSYS", and click on "MSYS-1.0.10.exe" (or whatever the latest version is - what is important is the ".exe" extension).
Run this file - the default options should be fine.
When it finishes the installation, a black prompt window appears. Confirm that you do want to normalize, and that you have a MinGW installation (type 'y' and press return), and then type in the folder where you have Dev-C++ installed, using forward slashes and lowercase: for me, that is "c:/dev-cpp". Press return.
Go to "C:\Dev-Cpp\bin" (or equivalent) and make a copy of "mingw32-make.exe". Rename this copy "make.exe". This is because the MSYS installation removes "make.exe" without the prefix, causing Dev-C++ to become confused when trying to compile using a makefile.
I'm having trouble with step 6.
At the end of the installation a prompt did come up like below:
Since it is an msys / mingw issue, you might try www.mingw.org
One of the 'benefits' of Dev-C++ is that it hides or the nasty details of the GNU toolchain, so this is probably not the best place to ask.
I am not sure about teh mention of cygwin in teh error message. Do you have Cygwin installed as well? That could well cause a conflict - Cygwin seldom plays well with other GNU based Win32 tools in my experience.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't remember having installed Cygwin.
And searching it didn't show up an exe with the filename cygwin (a dll for some other program and a python file).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had problems caused by Cygwin that have persisted even after Cygwin was uninstalled. You may need to scan your registry to eradicate it. But on the other hand you may need the application that is relying on it.
Cygwin provides a Linux emulation layer so that code written for Linux can be recompiled and executed on Win32. I have used it as a development environment to support the use of GCC cross-compilers, but a number of other tools I have used require Cygwin and often install their own copies which can cause conflicts.
Cygwin is not just a DLL, it is an huge suite of tools and GNU utilities, the DLL is merely the runtime support for Cygwin applications. Cygwin tools have the same names as MinGW tools (they are essentially the same tools recompiled to a different runtime, but MinGW versions run as native Win32 applications, without the need for the Linux emulation). If any of these tools appear in your PATH environment variable ahead of the MinGW installation, the wron tool will be used and may not run correctly.
Additionally I have experienced problems with different versions of sh.exe which appears to be the problem here. Try running C:\msys\1.0\bin\sh.exe directly with no script. At the risk of 'polluting' your Msys installation, you might try temporailly replasing sh.exe with the http://unxutils.sourceforge.net/ version.
Proceed with caution however, there is a chance of ending up with wholly incompatible mess.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> If any of these tools appear in your PATH environment variable ahead of the MinGW installation, the wron tool will be used and may not run correctly
My path variable is as follows:
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%NpmLib%;C:\Dev-Cpp\bin
Should I change the order?
>> Try running C:\msys\1.0\bin\sh.exe directly with no script.
What does this program do before I mess anything up?
>> At the risk of 'polluting' your Msys installation, you might try temporailly replasing sh.exe with the http://unxutils.sourceforge.net/ version.
I don't like the word risk.
Why is it that hard to just install a simple library?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It won't hurt to try. Your path comprises of other environment variables. I wonder what they all resolve to. To find out, open a cmd session (command console) and enter 'path'. This will display the fully resolved path. Copy & Paste that instead.
>> What does this program do before I mess anything up?
It is command shell, (like bash or cmd.exe). Should just open a console Window with a command prompt. The way it is used in your build it is passed a command script (pi.sh) to be executed. I was just interested in whether it fails on its own rather than part of a build.
>> I don't like the word risk.
Very wise. I merely meant that if you try lots of things that do not work or reveal anything, and do not (or cannot) 'undo' them, you may cause further problems that are unrelated to the original one. Backup any files that you overwrite and create a Restore Point is probably wise.
>> Why is it that hard to just install a simple library?
Sometimes it is. The problem with Open Source is everyone's environment is different, and many projects, like this one are developed and built on Linux. What is hard is making Windows look enough like Linux to support the build process.
There used to be a DevPak for this, but it seems to have disappeared from the web. If you are prepared to pay for one it does still appear to be available here: http://rapidshare.com/files/5881375/GMP.DevPak.html, I got the link from here: http://otfans.net/archive/index.php?t-73610.html which was the previous host of the DevPak. Select the free download, and wait for the timeout, and it will allow you to download it. All the usual cautions regarding downloads should be taken (viurus scan it!).
If it works, the DevPak can be installed by double clicking it, and Dev-C++'s package manager will install the pre-built library.
If it does not work, report back, I'll see if I can take the time to look at the tutorial. If we can get it to work, it may be worth creating and uploading a new DevPak.
Clifford
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My path is:
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Norman\Npm\Bin;C
:\Dev-Cpp\bin
Opening sh1:
It flashed and closed.
The Dev-pack:
I downloaded it, virus scanned it and its 822kB big.
I installed it and did a quick test:
include <gmpxx.h>
include <iostream>
using namespace std;
int main (void)
{
mpz_class a, b, c;
a = 1234;
b = "-5678";
c = a+b;
cout << "sum is " << c << "\n";
cout << "absolute value is " << abs(c) << "\n";
system("pause");
return 0;
}
And it worked perfectly. Thank you very much for helping me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have Dev-Cpp 4.9.9.2
I have winXP SP2.
I downloaded GMP 4.2.2 as a bz2 file and saved it in my documents. I can open bz2 files with IZArc.
The I googled for a tutorial to install GMP on windows and found the following link containing step-by-step instructions: http://suchideas.com/journal/2007/07/installing-gmp-on-windows/
Copy of the page:
The Preparation
Go to "C:\Dev-Cpp\bin" (or equivalent) and make a copy of "mingw32-make.exe". Rename this copy "make.exe". This is because the MSYS installation removes "make.exe" without the prefix, causing Dev-C++ to become confused when trying to compile using a makefile.
I'm having trouble with step 6.
At the end of the installation a prompt did come up like below:
==============
C:\msys\1.0\postinstall>PATH ..\bin;C:\Program Files\Mozilla Firefox;C:\WINDOWS\ system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Norman\Npm\Bin;C:\Dev-Cpp\bin
C:\msys\1.0\postinstall>..\bin\sh.exe pi.sh
AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x150000, State 0x10000
C:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 erro
r 6
C:\msys\1.0\postinstall>pause
Press any key to continue...
============
When I pressed a key the application just closed. What should I do now?
Since it is an msys / mingw issue, you might try www.mingw.org
One of the 'benefits' of Dev-C++ is that it hides or the nasty details of the GNU toolchain, so this is probably not the best place to ask.
I am not sure about teh mention of cygwin in teh error message. Do you have Cygwin installed as well? That could well cause a conflict - Cygwin seldom plays well with other GNU based Win32 tools in my experience.
Clifford
I don't remember having installed Cygwin.
And searching it didn't show up an exe with the filename cygwin (a dll for some other program and a python file).
If you have cygwin1.dll in your path somewhere, it can cause some issues.
Wayne
>> If you have cygwin1.dll in your path somewhere, it can cause some issues.
I do have such a DLL in C:\Program Files\3GP_Converter034\cores
But shouldn't this location be out of reach? It isn't in my Path variable.
However, I tried temporaly renaming this cygwin1.dll by cygwin2.dll
I got the same prompt output, though.
I have had problems caused by Cygwin that have persisted even after Cygwin was uninstalled. You may need to scan your registry to eradicate it. But on the other hand you may need the application that is relying on it.
Cygwin provides a Linux emulation layer so that code written for Linux can be recompiled and executed on Win32. I have used it as a development environment to support the use of GCC cross-compilers, but a number of other tools I have used require Cygwin and often install their own copies which can cause conflicts.
Cygwin is not just a DLL, it is an huge suite of tools and GNU utilities, the DLL is merely the runtime support for Cygwin applications. Cygwin tools have the same names as MinGW tools (they are essentially the same tools recompiled to a different runtime, but MinGW versions run as native Win32 applications, without the need for the Linux emulation). If any of these tools appear in your PATH environment variable ahead of the MinGW installation, the wron tool will be used and may not run correctly.
Additionally I have experienced problems with different versions of sh.exe which appears to be the problem here. Try running C:\msys\1.0\bin\sh.exe directly with no script. At the risk of 'polluting' your Msys installation, you might try temporailly replasing sh.exe with the http://unxutils.sourceforge.net/ version.
Proceed with caution however, there is a chance of ending up with wholly incompatible mess.
Clifford
>> If any of these tools appear in your PATH environment variable ahead of the MinGW installation, the wron tool will be used and may not run correctly
My path variable is as follows:
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%NpmLib%;C:\Dev-Cpp\bin
Should I change the order?
>> Try running C:\msys\1.0\bin\sh.exe directly with no script.
What does this program do before I mess anything up?
>> At the risk of 'polluting' your Msys installation, you might try temporailly replasing sh.exe with the http://unxutils.sourceforge.net/ version.
I don't like the word risk.
Why is it that hard to just install a simple library?
>> Should I change the order?
It won't hurt to try. Your path comprises of other environment variables. I wonder what they all resolve to. To find out, open a cmd session (command console) and enter 'path'. This will display the fully resolved path. Copy & Paste that instead.
>> What does this program do before I mess anything up?
It is command shell, (like bash or cmd.exe). Should just open a console Window with a command prompt. The way it is used in your build it is passed a command script (pi.sh) to be executed. I was just interested in whether it fails on its own rather than part of a build.
>> I don't like the word risk.
Very wise. I merely meant that if you try lots of things that do not work or reveal anything, and do not (or cannot) 'undo' them, you may cause further problems that are unrelated to the original one. Backup any files that you overwrite and create a Restore Point is probably wise.
>> Why is it that hard to just install a simple library?
Sometimes it is. The problem with Open Source is everyone's environment is different, and many projects, like this one are developed and built on Linux. What is hard is making Windows look enough like Linux to support the build process.
There used to be a DevPak for this, but it seems to have disappeared from the web. If you are prepared to pay for one it does still appear to be available here: http://rapidshare.com/files/5881375/GMP.DevPak.html, I got the link from here: http://otfans.net/archive/index.php?t-73610.html which was the previous host of the DevPak. Select the free download, and wait for the timeout, and it will allow you to download it. All the usual cautions regarding downloads should be taken (viurus scan it!).
If it works, the DevPak can be installed by double clicking it, and Dev-C++'s package manager will install the pre-built library.
If it does not work, report back, I'll see if I can take the time to look at the tutorial. If we can get it to work, it may be worth creating and uploading a new DevPak.
Clifford
Clifford
My path is:
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Norman\Npm\Bin;C
:\Dev-Cpp\bin
Opening sh1:
It flashed and closed.
The Dev-pack:
I downloaded it, virus scanned it and its 822kB big.
I installed it and did a quick test:
include <gmpxx.h>
include <iostream>
using namespace std;
int main (void)
{
mpz_class a, b, c;
And it worked perfectly. Thank you very much for helping me.
Cool. I wonder if it is the latest version? If not maybe you will still want to look at re-building sometime.
What does C:\Norman\Npm\Bin contain? Maybe a conflict there?
Sounds like sh.exe may not be the real problem, but perhaps pi.sh script itself.
I may take a look at it myself at some point.
Clifford