> On 6/30/2011 05:20, Torbjorn Granlund wrote:
 >>
>> Currently (i think) GMP configures and builds under MinGW-64, but GMP's
>> performance leaves a lot to be desired, mainly since the GMP x86_64
>> assembly does not work with Windows64's calling conventions.  (GMP's
>> performance is very dependent on assembly code, unfortunately.)
>>
>> We'd like to improve things in a two steps:
>>
>> (1) Make the existing assembly code work by adding a rather simple layer
>>      of abstraction to it.  We will still require a bash-type shell and
>>      other unix-like commands, like e.g., m4 and make.
>>
>> (2) Perhaps make things work, at least to some degree, with a more
>>      Windowsy environment.
>>
>> Questions:
>>
>> Do people here agree that GMP works today (w/o assembly)?

Yes, I agree that GMP works on 64-bit Windows (w/o assembly).  I currently have 
Windows XP Pro x64 as my OS and I use GMP for many of my own programs.  I also 
use it with GMP-ECM to good effect.

Can indeed
>> MinGW-64 run configure and 'make'?

Mingw64 provides ar,as,gcc,cpp,ranlib,gdb,ld and several other executables, all 
the *.h and lib*.a files.  You need to have an MSYS shell to run configure and 
make.

Would I need to install external
>> software, e.g., (parts of) Cygwin to make it work?

I'd recommend MSYS as your shell.  I have been through this process several 
times recently (setting up mingw64 with msys and building gmp on a Windows XP 
x64 computer).  There are just a few zip files you can download to get up and 
running.  I'll explain the process at the end of this e-mail.

>>
>> For step (1) above, will one have m4 from MinGW, or will that require
>> external software (e.g., Cygwin)?  Do you see any other potential
>> problems?
>>

If you download MSYS, you will have access to m4.

>> I will worry about (2) at a later point.  The idea here is to not depend
>> on Unixisms, whatever that means.  Gcc from MinGW will certainly still
>> be useful (I suppose gcc can be run from within such systems as "Visual
>> Studio"?)
>>
>> (I am not at this list, please retain any CC to me.)
>>
>> PS. Which is the recommened way to get started with mingw?  I find
>> sources, but I really don't want to mess with setting up a cross
>> compiltion environment at this early stage.  Should I install by means
>> of Cygwin's installer?

Do you have access to a 64-bit Windows OS?  If so you can download two zip 
files 
and be up and running shortly thereafter.  The first download will be mingw64. 
The easiest way to get set up with this is to download a personal build made by 
Ozkan Sezer of MingW64.  You can download this zip file from their SourceForge 
page here:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/

If you have a 64-bit Windows OS, you can download the currently latest file:
/sezero_20110510/mingw-w64-bin_x86_64-mingw_20110510_sezero.zip

If you don't have a 64-bit Windows OS, you can download one of the other zip 
files and you will be setting up a cross-compile environment at that point.

Personally, I unzip that file to a simple location, such as:
C:\mingw64-20110510\
This helps me to remember which version of mingw64 I am using.

Then, the next step is to get MSYS.  Luckily, MingW64 hosts an MSYS environment 
that you can download as one zip file, and not have to worry about going 
through 
an installation process.  You can find the MSYS environment on their 
SourceForge 
page here:
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/

As of this writing the latest one there is the following:
MSYS-20110526.zip

I unzip this one to another simple directory like so:
C:\msys-20110526\
This helps me to remember which version of MSYS I am using.  Although, you can 
get actual MSYS version info from 'uname -a'.

To get MSYS to use the mingw64 from above as your compiler, you need to change 
the path in your MSYS profile.  You can edit the following file:
C:\msys-20110526\etc\profile
(using Notepad [part of Windows], or maybe even Notepad++ [download from the 
internet])
And change the 'export PATH' from:
-------------------------------------------------------
if [ $MSYSTEM == MINGW32 ]; then
   export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
-------------------------------------------------------
To:
-------------------------------------------------------
if [ $MSYSTEM == MINGW32 ]; then
#  export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
   export PATH=".:/c/mingw64-20110510/bin:/usr/local/bin:/bin:$PATH"
-------------------------------------------------------

Then, to start up the MSYS shell, you can double-click the msys.bat file 
located 
in your MSYS folder.

If you right-click on the msys.bat file, you should get a list of options, one 
of them being "Send To", which has a sub-menu.  In that sub-menu you can select 
"Desktop (create shortcut)", this will put a shortcut on your desktop that you 
can use to launch MSYS without having to go clicking through folders each time 
you want to run MSYS.

At this point you can download GMP, I think you are familiar with this one. ;) 
If you'd like to download this with svn, you can get a good windows command 
line 
version from SourceForge here:
http://sourceforge.net/projects/win32svn/files/

Currently, the latest version is 1.6.17, which you can get from:
/1.6.17/svn-win32-1.6.17.zip
I unzip this to the following location (for 64-bit Windows):
c:\program files (x86)\svn-win32-1.6.17\

Then, to use it from a windows command prompt or inside MSYS, you need to 
change 
the Windows 'Path' environment variable.  To change this, click on Start, and 
Select the 'Control Panel' (or Start->Settings->Control Panel, depending on 
your 
set up).  Once in there, double-click 'System'.  Then select the 'Advanced' 
tab, 
and there should be a button at the bottom that says 'Environment Variables'. 
Click that, and at the bottom of this window you should see a list of 'System 
Variables'.  Scroll down until you see the 'Path' variable.  You can 
double-click this to edit it.  At this point we just want to add the svn\bin 
path at the end of this list of paths.  So, make sure you have a ';' semi-colon 
at the end of the list and then put the path to svn after it, like so:
;C:\Program Files (x86)\svn-win32-1.6.17\bin
Click OK to complete this, click OK to close the 'Environment Variables' 
window, 
and click OK to close the system properties.  Now you can open up a new command 
prompt or MSYS shell and use svn like normal.

Actually, I always download the latest gmp zip from your web site.  But, for 
other projects that I do download from svn, I download them to one svn 
directory, and then copy that to a different folder to do my compiling.  For 
example, I would have:
c:\gmp\svn\
c:\gmp\svn501\
c:\gmp\svn502\
This way I can leave the files in svn alone and do as much as I want with the 
files in the other directories.

So, to build gmp, first bring up an MSYS shell, then cd to your gmp directory. 
Since config.guess doesn't guess my system very well, I have to pass build and 
host options to it.  This isn't for cross-compiling, it is just to make sure 
that configure chooses the correct values for the compiling we are about to do. 
  So, my gmp configure line looks like:
./configure --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32
Then I can run 'make' and 'make check' and everything is fine, except for the 
bugs that I have already reported.

Oh, actually, if I remember right, if you have link.exe or nm.exe, the 
configure 
script will die with a strange error.  (Maybe I should turn in another bug 
report?)  But, if you go into the c:\msys-20110526\bin\ folder and rename both 
files from link.exe and nm.exe to link.old and nm.old, the configure process 
should complete just fine.

Whew, that was a lot of instructions.  I hope most of that made sense.  Please 
let me know if you run into any troubles or would like a better explanation of 
any of the above steps.  Let us know how it goes.

-David C.

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to