From: David C. <wr...@mo...> - 2008-03-21 01:17:46
|
Hello everyone, I would like to start using mingw-w64, but am unsure of what to do. I've just downloaded the latest mingw-w64-bin-x86_64-mingw_20080320.tar.bz2 and extracted it to its own folder "c:\mw64". I'm running Windows XP 64-bit edition and would like to build 64-bit windows binaries. I'd like to build gmp (and maybe someday mpfr, but that's secondary) and then other projects that depend on gmp. I'm a bit lost and I've got a lot of questions, so I guess I'll get started: 1) Do I need to add "c:\mw64\bin" to my path? 2) Are there any additional folders that I need to add to my path? 3) Do I need to run this inside of msys or cygwin for it to work? Or will running it inside the windows 64-bit command prompt suffice? (with the right path(s) in place) 4) Why is "c:\mw64\bin\gcc.exe" a 0 byte file? 5) Do I need to make a shortcut (or similar?) to point that gcc.exe to "c:\mw64\bin\x86_64-pc-mingw32-gcc-4.4.0.exe"? 6) Why is c:\mw64\bin\x86_64-pc-mingw32-gcc.exe a 0 byte file? 7) Why are all the files in C:\mw64\x86_64-pc-mingw32\bin 0 byte files? 8) With several bin, include, and lib folders, do I need to put any or all in my path, or maybe: once I've put the correct bin in my path, the tools will find the appropriate lib/include that they need? Well, that should get me started. ;) Thanks to anyone who would like to tackle these amateur-ish questions. -David C. |
From: NightStrike <nig...@gm...> - 2008-03-21 01:55:25
|
On 3/20/08, David Cleaver <wr...@mo...> wrote: > Hello everyone, Hi! > I would like to start using mingw-w64, but am unsure of what to do. Emailing here is a good start :) > I've just downloaded the latest mingw-w64-bin-x86_64-mingw_20080320.tar.bz2 and extracted > it to its own folder "c:\mw64". I'm running Windows XP 64-bit edition and would > like to build 64-bit windows binaries. I'd like to build gmp (and maybe someday > mpfr, but that's secondary) and then other projects that depend on gmp. I'm a > bit lost and I've got a lot of questions, so I guess I'll get started: > > 1) Do I need to add "c:\mw64\bin" to my path? Yup. I'd put it first, too: PATH=C:\mw64\bin;%PATH% > 2) Are there any additional folders that I need to add to my path? Not that I know of. > 3) Do I need to run this inside of msys or cygwin for it to work? Or will > running it inside the windows 64-bit command prompt suffice? (with the right > path(s) in place) Running it in cygwin should fail, actually, because this binary expects paths to be in Windows format (C:\...) Using cmd.exe should work just fine. > 4) Why is "c:\mw64\bin\gcc.exe" a 0 byte file? Erm.. because I made a big mistake? Or maybe you did when extracting it :) I really have to remember to use "-h" when making that tar file. If you use a real tar program and not winrar, it should work fine. You can use cygwin to extract it, or gnulib's tar, or some other tar program. With the next snapshot I make, I'll try to tar it better. > 5) Do I need to make a shortcut (or similar?) to point that gcc.exe to > "c:\mw64\bin\x86_64-pc-mingw32-gcc-4.4.0.exe"? Nope. > 6) Why is c:\mw64\bin\x86_64-pc-mingw32-gcc.exe a 0 byte file? See above. > 7) Why are all the files in C:\mw64\x86_64-pc-mingw32\bin 0 byte files? See above. > 8) With several bin, include, and lib folders, do I need to put any or all in my > path, or maybe: once I've put the correct bin in my path, the tools will find > the appropriate lib/include that they need? The binary should find the libraries automatically relative to where it;s installed.. > Well, that should get me started. ;) Thanks to anyone who would like to tackle > these amateur-ish questions. They're not amateur at all. They're actually a good indicator for me for mistakes that I'm making :) :) Thanks for the feedback! |
From: David C. <wr...@mo...> - 2008-03-21 02:58:30
|
NightStrike wrote: > On 3/20/08, David Cleaver wrote: >> 1) Do I need to add "c:\mw64\bin" to my path? > > Yup. I'd put it first, too: PATH=C:\mw64\bin;%PATH% Awesome! After using tar under cygwin (I originally used a program called 7-zip) to re-extract all the files to c:\mw64, all the files appear to be normal. One thing I noticed, there was no make.exe available. Perhaps its not supposed to be included? Anyway, Since I have msys/mingw installed, I set my path to: PATH=C:\mw64\bin;c:\msys\1.0\bin;%PATH% And I now have access to make, m4, and various other things needed by gmp. Is this the correct thing to do? > Running it in cygwin should fail, actually, because this binary > expects paths to be in Windows format (C:\...) Using cmd.exe should > work just fine. I have another question, which may or may not belong on another list, but, is it possible to run shell scripts (./configure or ./config.guess)? Now that I type this I'm thinking I should maybe run sh. Ok, just tried that and when I run ls or dir it gives errors such as: sh-2.04$ ls C:\msys\1.0\bin\sh.exe: *** fork: can't reserve memory for stack 0x480000 - 0x68 0000, Win32 error 0 0 [main] sh 6992 sync_with_child: child 8544(0x2C0) died before initializa tion with status code 0x1 1922 [main] sh 6992 sync_with_child: *** child state waiting for longjmp sh: fork: Resource temporarily unavailable Perhaps my sh is too old? I'll try to update that here shortly. >> 4) Why is "c:\mw64\bin\gcc.exe" a 0 byte file? > > Erm.. because I made a big mistake? Or maybe you did when extracting it :) Yup, my fault. The first program I tried was 7-zip. Apparently I'm not using it correctly. :) Or, maybe it's faulty! ;) > Thanks for the feedback! And thank you for the quick (and very helpful) reply! Please let me know what you (or anyone else) think about my above questions. |
From: NightStrike <nig...@gm...> - 2008-03-21 03:17:29
|
On 3/20/08, David Cleaver <wr...@mo...> wrote: > > NightStrike wrote: > > On 3/20/08, David Cleaver wrote: > >> 1) Do I need to add "c:\mw64\bin" to my path? > > > > Yup. I'd put it first, too: PATH=C:\mw64\bin;%PATH% > > Awesome! After using tar under cygwin (I originally used a program called > 7-zip) to re-extract all the files to c:\mw64, all the files appear to be normal. Sweet :) > One thing I noticed, there was no make.exe available. Perhaps its not supposed > to be included? Anyway, Since I have msys/mingw installed, I set my path to: > PATH=C:\mw64\bin;c:\msys\1.0\bin;%PATH% > > And I now have access to make, m4, and various other things needed by gmp. Is > this the correct thing to do? That's what I'd do. It makes life a little easier. You can also look at the gnuwin32 project for useful tools on the windows platform. There's also MS's own Services for Unix (current version is 3.5), SFU for short. > > Running it in cygwin should fail, actually, because this binary > > expects paths to be in Windows format (C:\...) Using cmd.exe should > > work just fine. > > I have another question, which may or may not belong on another list, but, is it > possible to run shell scripts (./configure or ./config.guess)? Now that I type > this I'm thinking I should maybe run sh. Ok, just tried that and when I run ls > or dir it gives errors such as: configure requires bourne shell or compatible. You won't get that natively without possibly Microsoft's PowerShell. One of these days I'll be able to port bash to native Windows..... > sh-2.04$ ls > C:\msys\1.0\bin\sh.exe: *** fork: can't reserve memory for stack 0x480000 - 0x68 > 0000, Win32 error 0 > 0 [main] sh 6992 sync_with_child: child 8544(0x2C0) died before initializa > tion with status code 0x1 > 1922 [main] sh 6992 sync_with_child: *** child state waiting for longjmp > sh: fork: Resource temporarily unavailable > > Perhaps my sh is too old? I'll try to update that here shortly. No, it's just not setup right. The msys.bat file configures a system properly based on if you're 64-bit windows or 32-bit windows. So start your shell with that instead of starting sh.exe directly. You can use the --norxvt option to msys.bat to use a normal windows console window instead of rxvt. > >> 4) Why is "c:\mw64\bin\gcc.exe" a 0 byte file? > > > > Erm.. because I made a big mistake? Or maybe you did when extracting it :) > > Yup, my fault. The first program I tried was 7-zip. Apparently I'm not using > it correctly. :) Or, maybe it's faulty! ;) It's both of us. I need to find a way to make these tar files compatible with normal windows tools. I think the issue comes down to hard links. What I might do is untar it using cygwin tar, then zip it up again with WinRAR. See, they're built originally on a linux system. It's a mess, I know.... > > Thanks for the feedback! > > And thank you for the quick (and very helpful) reply! Please let me know what > you (or anyone else) think about my above questions. They're exactly what this project needs. Tell your friends! :) |
From: David C. <wr...@mo...> - 2008-03-21 04:17:31
|
NightStrike wrote: > No, it's just not setup right. The msys.bat file configures a system > properly based on if you're 64-bit windows or 32-bit windows. So > start your shell with that instead of starting sh.exe directly. You > can use the --norxvt option to msys.bat to use a normal windows > console window instead of rxvt. OK, I'm using msys. I've figured out how to change the path there. I went to gmp and ran "./configure --host=x86_64-pc-mingw32" and then came across an error. While configure is running, it checks to see if it can find a working compiler. It failed and said to check the log file. When I looked in the log file, I came across this: configure:3851: checking compiler x86_64-pc-mingw32-gcc -O2 -m64 Test compile: configure:3865: x86_64-pc-mingw32-gcc -O2 -m64 conftest.c >&5 conftest.c: In function 'main': conftest.c:2: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. configure:3868: $? = 1 failed program was: int main () { return 0; } configure:4874: result: no Now, I tried to compile that same program on my own like: x86_64-pc-mingw32-gcc -o test.exe test.c And it worked fine. But, when I tried it the way the config file tried it: x86_64-pc-mingw32-gcc -O2 -m64 test.c It failed, just like it did for the script. Any ideas on what might be going wrong here? It fails whether or not I use rxvt, so that shouldn't be an issue. |
From: NightStrike <nig...@gm...> - 2008-03-21 12:41:29
|
On 3/21/08, David Cleaver <wr...@mo...> wrote: > > > NightStrike wrote: > > No, it's just not setup right. The msys.bat file configures a system > > properly based on if you're 64-bit windows or 32-bit windows. So > > start your shell with that instead of starting sh.exe directly. You > > can use the --norxvt option to msys.bat to use a normal windows > > console window instead of rxvt. > > OK, I'm using msys. I've figured out how to change the path there. I went to > gmp and ran "./configure --host=x86_64-pc-mingw32" and then came across an > error. While configure is running, it checks to see if it can find a working > compiler. It failed and said to check the log file. When I looked in the log > file, I came across this: > > configure:3851: checking compiler x86_64-pc-mingw32-gcc -O2 -m64 > Test compile: > configure:3865: x86_64-pc-mingw32-gcc -O2 -m64 conftest.c >&5 > conftest.c: In function 'main': > conftest.c:2: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <http://gcc.gnu.org/bugs.html> for instructions. > configure:3868: $? = 1 > failed program was: > > int main () { return 0; } > configure:4874: result: no > > > Now, I tried to compile that same program on my own like: > x86_64-pc-mingw32-gcc -o test.exe test.c > And it worked fine. > > But, when I tried it the way the config file tried it: > x86_64-pc-mingw32-gcc -O2 -m64 test.c > It failed, just like it did for the script. > > Any ideas on what might be going wrong here? It fails whether or not I use > rxvt, so that shouldn't be an issue. >From the looks of things, it means that optimization is broken pretty badly... Try setting CFLAGS to -O0 before running configure. do something like: ./configure CFLAGS=-O0 host=x86_64-pc-mingw32 |
From: NightStrike <nig...@gm...> - 2008-03-25 13:16:58
|
On 3/25/08, whatis neveritis <wha...@go...> wrote: > are the files in: > > root-x86_64-pc-linux/mingw/bin/ > > hard links toward files in: > > root-x86_64-pc-linux/ > > ? Hard links don't exist on windows, so they are copies of each other. root/bin holds default programs (gcc, ld, etc). root/mingw/bin holds specific programs(x86_64-pc-mingw32-gcc). This is so that you can have multiple-targetted compilers installed on the same system, and have the files in root/bin point to the one you want to use as default. |
From: NightStrike <nig...@gm...> - 2008-03-25 13:21:48
|
On 3/25/08, whatis neveritis <wha...@go...> wrote: > > > > > > 5) Do I need to make a shortcut (or similar?) to point that gcc.exe to > > > "c:\mw64\bin\x86_64-pc-mingw32-gcc-4.4.0.exe"? > > > > Nope. > > > > Then how is the compiler meant to be invoked? By typing "gcc" or > "x86_64-pc-mingw32-gcc-4.4.0" ? Either one. "gcc" invokes wahtever compiler you set as default. x86_64...-gcc invokes a specific compiler. Imagine a situation where you have both an x86_64-pc-mingw32 compiler and an i686-pc-mingw32 compiler installed on the same system. "gcc" would point to one of them (most likely as a direct copy, since links don't really exist too readily on windows). To access the other, or to access a specific one when you are not sure what the default does, you call the longer canonicalized name. > Also how are ld, as, ar and so on meant to be found? > > If a makefile compiles object files using gcc, then uses ar to create an > archive, how will the correct ar be found? They are found relative to the directory from which gcc is executed. Type "gcc -v" to see the search paths used. You can also do "gcc -v -c file.c" to see in detail what goes on and how different things are found. "gcc -print-search-dirs" also helps in finding where gcc looks to find other programs. > Does the makefile need to know it needs to use those binaries specifically? make will sometimes set ar, ld, etc appropriately. It depends on how the makefile is set up. > Also, regarding cross compiling in linux, what if code has #if defined > (WIN32) type preprocessor defs around, do they need to be defined by hand? I'm pretty sure that our compiler defines WIN32. Kai can correct me on this. > Does that mean configure scripts & makefiles need to be written with mingw > cross compiling in linux for windows in mind? In a perfect world, no. At least, not as far as compiler choice is concerned. If the code isn't portable, though, it'll have to be updated. For instance, if it relies on some unix-only functionality, that part of the code will have to be updated. configure scripts and makefiles, however, should be portable by definition. |
From: NightStrike <nig...@gm...> - 2008-03-25 13:26:22
|
On 3/25/08, whatis neveritis <wha...@go...> wrote: > Eeps sorry that wasn't clear, > > So: > > |-- mingw -> x86_64-pc-mingw32 > > mingw is a symlink towards x86_64-pc-mingw32 Only on file systems that support symlinks. I'll repackage the windows-hosted packages without any ambiguity in links. > But now what are the files in that folder? "x86_64-pc-mingw32" > > What does the "x86_64-pc-mingw32/bin" folder contain? > > and how do these files differ from those in the root 'bin' folder? > > What does the "x86_64-pc-mingw32/bin" folder contain? The directory structure starting at x86_64-pc-mingw32 is any target-specific libraries, includes, and binaries. For instance, our headers and libs live there. The bin directory contains all of the binaries prefixed with "x86_64-pc-mingw32" to denote the specific target. In the case of the packages that I provide, these binaries are the same as the one in root/bin, albeit with non-canonicalized names. > Why is there an empty include folder in the root? I'm not sure. Hopefully, I won't forget to look into it. > What does the "x86_64-pc-mingw32/lib" folder contain? The crt runtime (the libraries specific to the x86_64-pc-mingw32 target) > And what do the lib and lib64 folders in the root contain? These, I believe, are for libraries like libiberty. I'm not sure about this directory structure. I imagine this is more system libraries (libraries for the system you are running on) > Sorry for all the questions. Keep 'em coming. And feel free to create a FAQ and update it in the Wiki....... |
From: NightStrike <nig...@gm...> - 2008-03-25 21:06:17
|
On 3/25/08, whatis neveritis <wha...@go...> wrote: > > > And feel free to create a FAQ and update it in the Wiki....... > > > > What about a README in the project root? > > Or maybe a base README template which gets used to generate a README > appropriate for the specific project it gets run for? > > I find wikis get out of date from the word go. On the contrary, by their very nature, wiki's are much more up to date than a README file. As a result, most README's these days contain only a link to online versions of the documentation. With a wiki, anyone can contribute very easily. With a README, it takes much more effort to make a change. |