From: Joost K. <J.Kraaijeveld@Askesis.nl> - 2010-03-01 14:17:19
|
Hi, I am using MSYS/MinGW on Windows XP which is running as a guest in a Debian AMD64 Squeeze machine. The performance is rather bad: a simple "configure" easily takes 5 minutes and the following compile of a short "Hello world" style program takes about the same amount of time. On a "real" Windows machine these operations take 1 minute and ~10 secs. Does anyone have the same experience, and does anyone know a solution for this? Or at what I could look to improve the situation? TIA -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl |
From: Vincent T. <vt...@un...> - 2010-03-01 14:33:41
|
On Mon, 1 Mar 2010, Joost Kraaijeveld wrote: > Hi, > > I am using MSYS/MinGW on Windows XP which is running as a guest in a > Debian AMD64 Squeeze machine. The performance is rather bad: a simple > "configure" easily takes 5 minutes and the following compile of a short > "Hello world" style program takes about the same amount of time. On a > "real" Windows machine these operations take 1 minute and ~10 secs. > > Does anyone have the same experience, and does anyone know a solution > for this? Or at what I could look to improve the situation? In Windows itself (that is not in virtualbox), the configure / compilation time is uber-long, so in virtualbox, it just can't be faster. Vincent Torri |
From: LRN <lr...@gm...> - 2010-03-01 17:07:04
|
On 01.03.2010 17:33, Vincent Torri wrote: > > On Mon, 1 Mar 2010, Joost Kraaijeveld wrote: > > >> Hi, >> >> I am using MSYS/MinGW on Windows XP which is running as a guest in a >> Debian AMD64 Squeeze machine. The performance is rather bad: a simple >> "configure" easily takes 5 minutes and the following compile of a short >> "Hello world" style program takes about the same amount of time. On a >> "real" Windows machine these operations take 1 minute and ~10 secs. >> >> Does anyone have the same experience, and does anyone know a solution >> for this? Or at what I could look to improve the situation? >> > In Windows itself (that is not in virtualbox), the configure / compilation > time is uber-long, so in virtualbox, it just can't be faster. > > Vincent Torri > I've filed a bug to VBox devs about mingw's version of gcc crashing a Windows XP guest (running on Windows XP x64 host). Maybe they've fixed it, or maybe not. Regardless, i have experienced high (~100%) CPU utilization by gcc (don't remember about configure scripts being slow or not) and utterly slow performance. I gave up and now i'm using real Windows to compile things with my buildbot. |
From: Keith M. <kei...@us...> - 2010-03-02 19:23:20
Attachments:
times.txt
|
On Monday 01 March 2010 14:33:32 Vincent Torri wrote: > > I am using MSYS/MinGW on Windows XP which is running as a guest > > in a Debian AMD64 Squeeze machine. The performance is rather > > bad: a simple "configure" easily takes 5 minutes and the > > following compile of a short "Hello world" style program takes > > about the same amount of time. On a "real" Windows machine these > > operations take 1 minute and ~10 secs. > > > > Does anyone have the same experience, and does anyone know a > > solution for this? Or at what I could look to improve the > > situation? > > In Windows itself (that is not in virtualbox), the configure / > compilation time is uber-long, so in virtualbox, it just can't be > faster. You would certainly expect that, but comparisons can be misleading. However, the OP did *not* just complain that his VirtualBox setup was _slightly_ slower than a real Windows machine, (which we might expect); he said it was _an order of magnitude_ slower, which we might not expect. I certainly am *not* seeing any such phenomenon; indeed, for me I see *better* performance in a VirtualBox guested WinXP on my Ubuntu-8.04 1.5GHz Celeron (32-bit) laptop, (with only 192MB of RAM allocated to the virtual machine), than I do on a real Win2K host with 2.8GHz Pentium-D (also 32-bit) processor, and 1GB of RAM. See what I mean about comparisons being misleading; we would really expect better performance from the Win2K host, but all sorts of other background junk may cloud the issue. You are welcome to draw your own conclusions from the attached transcripts of mingw-get's configuration process, composited from three sessions:-- 1) MSYS-1.0.11 hosted on real Win2K box. 2) MSYS-1.0.11 hosted on guest WinXP in VirtualBox on Ubuntu-8.04. 3) Cross build [*], hosted on the same Ubuntu-8.04 box. [*] I've used the same version of MinGW's GCC in all cases; the details for my cross-hosted build of this are appended to case 3. -- Regards, Keith. |
From: Joost K. <J.Kraaijeveld@Askesis.nl> - 2010-03-03 12:04:21
|
Hi, I did a same kind of test Keith did: I ran the same configure on 3 different machines, each with the same msys/mingw/windows-os, an in case of the VirtualBox, the same virtual machine image. Native Windows XP SP3 ( Intel Pentium 4 2.4GHz , 2GB): real 1m22.654s user 0m54.602s sys 0m38.331s Debian AMD64 Squeeze / Windows XP SP3 (Dual AMD Opteron Processor 248 2.2 GHz, 8GB): real 3m33.861s user 0m43.591s sys 2m19.041s Debian AMD64 Squeeze / Windows XP SP3 (Intel Core 2 Duo CPU T7500 2.20GHz , 4GB): real 2m57.385s user 0m49.921s sys 1m44.594s What I see is the user-part is more or less the same in all three experiments but it is the system part that takes very long in the VirtualBox situation. This is the same in Keith's output (I assume he configured the same project three times). It appears to me that the "configure: creating ./config.status" part takes considerably longer in a VirtualBox session than on native Windows ans is responsible for much of the delay. Is there a way of finding out how an application spends it's time, apart from recompile an [ofile tha application? TIA -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl |
From: Keith M. <kei...@us...> - 2010-03-04 18:07:02
|
On Wednesday 03 March 2010 12:03:44 Joost Kraaijeveld wrote: > What I see is the user-part is more or less the same in all three > experiments but it is the system part that takes very long in the > VirtualBox situation. This is the same in Keith's output (I assume > he configured the same project three times). Yes, I ran configure on the mingw-get source snapshot I posted a week or so ago, in all three cases. However, you seem to be jumping to a conclusion which I *don't* think is *significantly* apparent in my data, (which seems reasonably representative and reproducible over three or four repetitions for each of the three cases, BTW). Yes, I can see that system time is 48.3% of elapsed time for the VirtualBox case, compared to 42.5% for the real Win2K case, but I can't say if this is a statistically significant difference, because I haven't performed enough tests; however, the difference between the two MSYS cases and the native Linux case at 17.2% likely is significant. A similar subjective analysis of the user mode times shows 56.1% for the real Win2K case, 25.6% for the VirtualBox case and 54.9% for the native Linux case. Once again, there may be no significance, but if anything my VirtualBox marginally outperforms the real Win2K host, even when run on less highly specified hardware. The only conclusion *I* will draw from this is that it is a waste of time setting up a virtual MS-Windows guest on a Linux host, to run MSYS and MinGW for building MS-Windows applications; rather set up a cross tool chain, directly hosted on the Linux box, and benefit from a performance boost of around 1000% .. 1400%, in terms of elapsed time, over any MS-Windows hosted build. -- Regards, Keith. |
From: Gregory C. <gre...@gm...> - 2010-03-04 18:53:16
|
On Thu, Mar 4, 2010 at 6:20 AM, Keith Marshall <kei...@us...> wrote: < SNIP > > > The only conclusion *I* will draw from this is that it is a waste of > time setting up a virtual MS-Windows guest on a Linux host, to run > MSYS and MinGW for building MS-Windows applications; rather set up a > cross tool chain, directly hosted on the Linux box, and benefit from > a performance boost of around 1000% .. 1400%, in terms of elapsed > time, over any MS-Windows hosted build. Just to add my $0.02, I don't necessarily think it's MSYS/MinGW. I believe the problem lays with GCC on Windows. On the GNUstep project we're using MSYS/MinGW to build applications on Windows. Compilation on Windows takes about 4-5 times longer than on Linux or other platforms, but performance of the applications themselves doesn't seem to suffer. GC -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) |
From: Natalie T. <nat...@in...> - 2010-03-09 19:04:56
|
Hi Keith, Joost, Arriving late to this thread, I can definitely lend my support that autoconf is *painfully* slow on a virtualized windows instance under VMWare, under either Mac OS X 10.5 and Ubuntu 9.04 hosts. Keith, we ofter hear that (to summarize) "it's not mingw's fault, it's Windows which is intrinsically slow". For my own understanding, I would love to hear a detailed explanation of what you think might be going on. Is it that Windows is really bad at opening file descriptors? Starting or switching processes? etc. (And if you've already discussed this on another thread, feel free to simply point me there, too.) Keith, you recommend a linux-hosted cross tool chain for building Windows apps. On mingw.org, I see the page " http://mingw.org/wiki/LinuxCrossMinGW", but that page hasn't been updated since Sept 2008 and I know (from watching this list) that there's been a lot of updates since. Could you please point me to more recent documentation, if any exists? Many thanks to Keith and the mingw team for their work on this very useful project. -Natalie On 3/4/10 3:20 AM, Keith Marshall wrote: > On Wednesday 03 March 2010 12:03:44 Joost Kraaijeveld wrote: > >> What I see is the user-part is more or less the same in all three >> experiments but it is the system part that takes very long in the >> VirtualBox situation. This is the same in Keith's output (I assume >> he configured the same project three times). >> > Yes, I ran configure on the mingw-get source snapshot I posted a week > or so ago, in all three cases. However, you seem to be jumping to a > conclusion which I *don't* think is *significantly* apparent in my > data, (which seems reasonably representative and reproducible over > three or four repetitions for each of the three cases, BTW). Yes, I > can see that system time is 48.3% of elapsed time for the VirtualBox > case, compared to 42.5% for the real Win2K case, but I can't say if > this is a statistically significant difference, because I haven't > performed enough tests; however, the difference between the two MSYS > cases and the native Linux case at 17.2% likely is significant. > > A similar subjective analysis of the user mode times shows 56.1% for > the real Win2K case, 25.6% for the VirtualBox case and 54.9% for the > native Linux case. Once again, there may be no significance, but if > anything my VirtualBox marginally outperforms the real Win2K host, > even when run on less highly specified hardware. > > The only conclusion *I* will draw from this is that it is a waste of > time setting up a virtual MS-Windows guest on a Linux host, to run > MSYS and MinGW for building MS-Windows applications; rather set up a > cross tool chain, directly hosted on the Linux box, and benefit from > a performance boost of around 1000% .. 1400%, in terms of elapsed > time, over any MS-Windows hosted build. > > |
From: Joost K. <J.Kraaijeveld@Askesis.nl> - 2010-03-10 05:23:55
|
Hi Natalie, A possible useful cross compile environment can be found here: http://www.nongnu.org/mingw-cross-env/#introduction I use it myself. And in case of problems, the list is very responsive. -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl |
From: Tatsh <dd...@gm...> - 2010-03-11 06:28:24
|
On Linux-hosted cross-compiling environment, I maintain a Wiki page here: http://en.gentoo-wiki.com/wiki/Mingw Yeah, GDBM (and its reverse deps) working would be great. Then I could just use Portage to emerge. The thing I cannot get Portage to do even with many options enabled is ignore that I have X in many cases. Other than that, if you build stuff from source yourself and maintain your root then it's fine. On Tuesday 09 March 2010 14:04:44 Natalie Tasman wrote: > Hi Keith, Joost, > > Arriving late to this thread, I can definitely lend my support that > autoconf is *painfully* slow on a virtualized windows instance under > VMWare, under either Mac OS X 10.5 and Ubuntu 9.04 hosts. > > Keith, we ofter hear that (to summarize) "it's not mingw's fault, it's > Windows which is intrinsically slow". For my own understanding, I would > love to hear a detailed explanation of what you think might be going > on. Is it that Windows is really bad at opening file descriptors? > Starting or switching processes? etc. (And if you've already discussed > this on another thread, feel free to simply point me there, too.) > > Keith, you recommend a linux-hosted cross tool chain for building > Windows apps. On mingw.org, I see the page " > http://mingw.org/wiki/LinuxCrossMinGW", but that page hasn't been > updated since Sept 2008 and I know (from watching this list) that > there's been a lot of updates since. Could you please point me to more > recent documentation, if any exists? > > Many thanks to Keith and the mingw team for their work on this very > useful project. > > -Natalie > > On 3/4/10 3:20 AM, Keith Marshall wrote: > > On Wednesday 03 March 2010 12:03:44 Joost Kraaijeveld wrote: > >> What I see is the user-part is more or less the same in all three > >> experiments but it is the system part that takes very long in the > >> VirtualBox situation. This is the same in Keith's output (I assume > >> he configured the same project three times). > > > > Yes, I ran configure on the mingw-get source snapshot I posted a week > > or so ago, in all three cases. However, you seem to be jumping to a > > conclusion which I *don't* think is *significantly* apparent in my > > data, (which seems reasonably representative and reproducible over > > three or four repetitions for each of the three cases, BTW). Yes, I > > can see that system time is 48.3% of elapsed time for the VirtualBox > > case, compared to 42.5% for the real Win2K case, but I can't say if > > this is a statistically significant difference, because I haven't > > performed enough tests; however, the difference between the two MSYS > > cases and the native Linux case at 17.2% likely is significant. > > > > A similar subjective analysis of the user mode times shows 56.1% for > > the real Win2K case, 25.6% for the VirtualBox case and 54.9% for the > > native Linux case. Once again, there may be no significance, but if > > anything my VirtualBox marginally outperforms the real Win2K host, > > even when run on less highly specified hardware. > > > > The only conclusion *I* will draw from this is that it is a waste of > > time setting up a virtual MS-Windows guest on a Linux host, to run > > MSYS and MinGW for building MS-Windows applications; rather set up a > > cross tool chain, directly hosted on the Linux box, and benefit from > > a performance boost of around 1000% .. 1400%, in terms of elapsed > > time, over any MS-Windows hosted build. > -- Tatsh www.tatsh.net dd...@gm... |
From: Tatsh <dd...@gm...> - 2010-03-11 06:28:26
|
This may not be so easy if you don't have Gentoo, but I maintain a Wiki page about Linux-hosted Mingw environment: http://en.gentoo-wiki.com/wiki/Mingw In general it works. Sometimes stuff still refuses to acknowledge it's 'Windows' of some sort (configure scripts). On Tuesday 09 March 2010 14:04:44 Natalie Tasman wrote: > Hi Keith, Joost, > > Arriving late to this thread, I can definitely lend my support that > autoconf is *painfully* slow on a virtualized windows instance under > VMWare, under either Mac OS X 10.5 and Ubuntu 9.04 hosts. > > Keith, we ofter hear that (to summarize) "it's not mingw's fault, it's > Windows which is intrinsically slow". For my own understanding, I would > love to hear a detailed explanation of what you think might be going > on. Is it that Windows is really bad at opening file descriptors? > Starting or switching processes? etc. (And if you've already discussed > this on another thread, feel free to simply point me there, too.) > > Keith, you recommend a linux-hosted cross tool chain for building > Windows apps. On mingw.org, I see the page " > http://mingw.org/wiki/LinuxCrossMinGW", but that page hasn't been > updated since Sept 2008 and I know (from watching this list) that > there's been a lot of updates since. Could you please point me to more > recent documentation, if any exists? > > Many thanks to Keith and the mingw team for their work on this very > useful project. > > -Natalie > > On 3/4/10 3:20 AM, Keith Marshall wrote: > > On Wednesday 03 March 2010 12:03:44 Joost Kraaijeveld wrote: > >> What I see is the user-part is more or less the same in all three > >> experiments but it is the system part that takes very long in the > >> VirtualBox situation. This is the same in Keith's output (I assume > >> he configured the same project three times). > > > > Yes, I ran configure on the mingw-get source snapshot I posted a week > > or so ago, in all three cases. However, you seem to be jumping to a > > conclusion which I *don't* think is *significantly* apparent in my > > data, (which seems reasonably representative and reproducible over > > three or four repetitions for each of the three cases, BTW). Yes, I > > can see that system time is 48.3% of elapsed time for the VirtualBox > > case, compared to 42.5% for the real Win2K case, but I can't say if > > this is a statistically significant difference, because I haven't > > performed enough tests; however, the difference between the two MSYS > > cases and the native Linux case at 17.2% likely is significant. > > > > A similar subjective analysis of the user mode times shows 56.1% for > > the real Win2K case, 25.6% for the VirtualBox case and 54.9% for the > > native Linux case. Once again, there may be no significance, but if > > anything my VirtualBox marginally outperforms the real Win2K host, > > even when run on less highly specified hardware. > > > > The only conclusion *I* will draw from this is that it is a waste of > > time setting up a virtual MS-Windows guest on a Linux host, to run > > MSYS and MinGW for building MS-Windows applications; rather set up a > > cross tool chain, directly hosted on the Linux box, and benefit from > > a performance boost of around 1000% .. 1400%, in terms of elapsed > > time, over any MS-Windows hosted build. > -- Tatsh www.tatsh.net dd...@gm... |
From: Earnie <ea...@us...> - 2010-03-11 12:45:00
|
Tatsh wrote: > This may not be so easy if you don't have Gentoo, but I maintain a > Wiki page about Linux-hosted Mingw environment: > > http://en.gentoo-wiki.com/wiki/Mingw > > In general it works. Sometimes stuff still refuses to acknowledge > it's 'Windows' of some sort (configure scripts). > > On Tuesday 09 March 2010 14:04:44 Natalie Tasman wrote: I'm happy to see you are promoting MinGW but not too happy that you break list etiquette and top post. http://www.mingw.org/mailing_lists Earnie |
From: Jonathan M. <jma...@fa...> - 2010-03-09 20:53:54
|
Natalie Tasman wrote: > Keith, we ofter hear that (to summarize) "it's not mingw's fault, > it's Windows which is intrinsically slow". For my own understanding, > I would love to hear a detailed explanation of what you think might > be going on. Process creation is widely acknowledged to be significantly slower under Windows than under Linux/Unix. Google found me this set of posts about it, for example; there are many many articles around talking about this: http://stackoverflow.com/questions/47845/why-is-creating-a-new-process-more-expensive-on-windows-than-linux This means that software written assuming fork is cheap runs more slowly under Windows. And autoconf works by running many many small test programs. > On mingw.org, I see the page "http://mingw.org/wiki/LinuxCrossMinGW", > but that page hasn't been updated since Sept 2008 and I know (from > watching this list) that there's been a lot of updates since. The script it runs was updated in March 2009, and the instructions on that wiki page remain valid, as far as I know. I just downloaded the tarball, unpacked it and ran the script, and 10 minutes later I had a functional cross-compilation environment. At that point, as a quick test I can do: echo -e 'main() {\nprintf("hello, world\\n");\n}' >hello.c ~/mingw/bin/i386-mingw32-gcc -o hello.exe hello.c file hello.exe and get hello.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit and indeed that hello.exe binary runs fine under Windows. Jonathan |
From: Keith M. <kei...@us...> - 2010-03-10 22:41:59
|
On Wednesday 10 March 2010 02:24:52 Natalie Tasman wrote: > Regarding the cross-compiling environment, I've gone through the > process myself, and here are my notes. I'm using > x86-mingw32-build-1.0.sh. > > 1) edit the .conf file to update packages to more recent versions, > where possible. binutils version 2.20.1-2 doesn't build for me > under ubuntu 9.04, with no useful error messages. Hmm. The error messages are there, but there is so much cruft spewed out after them, that they are difficult to spot. For me, Ubuntu-9.04 turned out to be an unmitigated disaster, (off-topic for this list), so I've reverted to 8.04, on which I found two pertinent problems:-- 1) The source tarball, on SF, has been incorrectly named. Chris, this is a generic source release from upstream; unless you've applied a local mingw32 specific patch, it should *not* include the mingw32 specific qualifier in the source tarball name, and doesn't require any further release serialisation number. As a QD work around, I downloaded manually, and renamed my locally cached copy (correctly), as binutils-2.20.1-src.tar.gz, which allowed me to progress to find... 2) The binutils folks have, (yet again), released a source package with a broken time stamp progression for the BFD info files; (on this occasion, the offender is bfd/doc/opncls.texi, derived from bfd/opncls.c, which is newer than, and a prerequisite of the shipped bfd/doc/bfd.info. I guess that you, in common with most Ubuntu users, don't have GNU texinfo installed, (Debian based Linuxes use their own incompatible info subsystem), so you don't have the tools to resolve this broken prerequisite at build time. To work around this /upstream/ bug, I've uploaded a repackaged and correctly named source tarball, with the offending texinfo files touched in correct sequence: http://prdownloads.sourceforge.net/mingw/binutils-2.20.1-src.tar.gz?download > gcc 3.4.5...-3 > doesn't have src tarballs, so you need ...-2: Correct. This is documented in the release notes, (directly visible and browsable on SF), for the gcc-3.4.5...-3 release packages. > assume GCC_VERSION 3.4.5-20060117-2 > assume BINUTILS_VERSION 2.19.1 > assume RUNTIME_VERSION 3.18 > assume W32API_VERSION 3.14 > > 2) manually download the following files; sourceforge has changed > their file release system since the script was authored, so the > script can no longer wget the files correctly. The CVS version of the scripts has already been modified to account for that SF change; I guess it's time to get that released: http://prdownloads.sourceforge.net/mingw/x86-mingw32-build-1.0.1-sh.tar.bz2?download > 3) run the program with i686-pc-mingw as the host argument; have > the script find the files downloaded in 2) rather than try to get > them itself. With my source package corrections, and the new scripts release, this configuration... assume GCC_VERSION 3.4.5-20060117-2 assume BINUTILS_VERSION 2.20.1 assume RUNTIME_VERSION 3.18 assume W32API_VERSION 3.14 should download and build fine; (it does for me). -- Regards, Keith. |
From: Natalie T. <nat...@in...> - 2010-03-11 06:13:52
|
On 3/10/10 2:41 PM, Keith Marshall wrote: > On Wednesday 10 March 2010 02:24:52 Natalie Tasman wrote: > >> Regarding the cross-compiling environment, I've gone through the >> process myself, and here are my notes. I'm using >> x86-mingw32-build-1.0.sh. >> >> 1) edit the .conf file to update packages to more recent versions, >> where possible. binutils version 2.20.1-2 doesn't build for me >> under ubuntu 9.04, with no useful error messages. >> > Hmm. The error messages are there, but there is so much cruft spewed > out after them, that they are difficult to spot. For me, Ubuntu-9.04 > turned out to be an unmitigated disaster, (off-topic for this list), > so I've reverted to 8.04, on which I found two pertinent problems:-- > > 1) The source tarball, on SF, has been incorrectly named. Chris, > this is a generic source release from upstream; unless you've applied > a local mingw32 specific patch, it should *not* include the mingw32 > specific qualifier in the source tarball name, and doesn't require > any further release serialisation number. > > As a QD work around, I downloaded manually, and renamed my locally > cached copy (correctly), as binutils-2.20.1-src.tar.gz, which allowed > me to progress to find... > > 2) The binutils folks have, (yet again), released a source package > with a broken time stamp progression for the BFD info files; (on > this occasion, the offender is bfd/doc/opncls.texi, derived from > bfd/opncls.c, which is newer than, and a prerequisite of the shipped > bfd/doc/bfd.info. I guess that you, in common with most Ubuntu > users, don't have GNU texinfo installed, (Debian based Linuxes use > their own incompatible info subsystem), so you don't have the tools > to resolve this broken prerequisite at build time. > > To work around this /upstream/ bug, I've uploaded a repackaged and > correctly named source tarball, with the offending texinfo files > touched in correct sequence: > http://prdownloads.sourceforge.net/mingw/binutils-2.20.1-src.tar.gz?download > > >> gcc 3.4.5...-3 >> doesn't have src tarballs, so you need ...-2: >> > Correct. This is documented in the release notes, (directly visible > and browsable on SF), for the gcc-3.4.5...-3 release packages. > > >> assume GCC_VERSION 3.4.5-20060117-2 >> assume BINUTILS_VERSION 2.19.1 >> assume RUNTIME_VERSION 3.18 >> assume W32API_VERSION 3.14 >> >> 2) manually download the following files; sourceforge has changed >> their file release system since the script was authored, so the >> script can no longer wget the files correctly. >> > The CVS version of the scripts has already been modified to account > for that SF change; I guess it's time to get that released: > http://prdownloads.sourceforge.net/mingw/x86-mingw32-build-1.0.1-sh.tar.bz2?download > > >> 3) run the program with i686-pc-mingw as the host argument; have >> the script find the files downloaded in 2) rather than try to get >> them itself. >> > With my source package corrections, and the new scripts release, this > configuration... > > assume GCC_VERSION 3.4.5-20060117-2 > assume BINUTILS_VERSION 2.20.1 > assume RUNTIME_VERSION 3.18 > assume W32API_VERSION 3.14 > > should download and build fine; (it does for me). > > Thanks, Keith! -Natalie |
From: Natalie T. <nat...@in...> - 2010-03-10 02:25:00
|
Jonathan, Thank you for the information. I'd suspected that something like process creation was the issue for autotools, with all of the associated test programs. Thanks for confirming that. Regarding the cross-compiling environment, I've gone through the process myself, and here are my notes. I'm using x86-mingw32-build-1.0.sh. 1) edit the .conf file to update packages to more recent versions, where possible. binutils version 2.20.1-2 doesn't build for me under ubuntu 9.04, with no useful error messages. gcc 3.4.5...-3 doesn't have src tarballs, so you need ...-2: assume GCC_VERSION 3.4.5-20060117-2 assume BINUTILS_VERSION 2.19.1 assume RUNTIME_VERSION 3.18 assume W32API_VERSION 3.14 2) manually download the following files; sourceforge has changed their file release system since the script was authored, so the script can no longer wget the files correctly. binutils-2.19.1-src.tar.gz gcc-core-3.4.5-20060117-2-src.tar.gz gcc-g++-3.4.5-20060117-2-src.tar.gz mingwrt-3.18-mingw32-src.tar.gz w32api-3.14-mingw32-src.tar.gz 3) run the program with i686-pc-mingw as the host argument; have the script find the files downloaded in 2) rather than try to get them itself. After about ~10 min, done! Thanks again for the details as well as verifying that the cross-compiler environment worked for you, today. Natalie On 3/9/10 12:53 PM, Jonathan Marsden wrote: > Natalie Tasman wrote: > > >> Keith, we ofter hear that (to summarize) "it's not mingw's fault, >> it's Windows which is intrinsically slow". For my own understanding, >> I would love to hear a detailed explanation of what you think might >> be going on. >> > Process creation is widely acknowledged to be significantly slower under > Windows than under Linux/Unix. Google found me this set of posts about > it, for example; there are many many articles around talking about this: > > http://stackoverflow.com/questions/47845/why-is-creating-a-new-process-more-expensive-on-windows-than-linux > > This means that software written assuming fork is cheap runs more slowly > under Windows. And autoconf works by running many many small test programs. > > >> On mingw.org, I see the page "http://mingw.org/wiki/LinuxCrossMinGW", >> but that page hasn't been updated since Sept 2008 and I know (from >> watching this list) that there's been a lot of updates since. >> > The script it runs was updated in March 2009, and the instructions on > that wiki page remain valid, as far as I know. I just downloaded the > tarball, unpacked it and ran the script, and 10 minutes later I had a > functional cross-compilation environment. At that point, as a quick > test I can do: > > echo -e 'main() {\nprintf("hello, world\\n");\n}'>hello.c > ~/mingw/bin/i386-mingw32-gcc -o hello.exe hello.c > file hello.exe > > and get > > hello.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit > > and indeed that hello.exe binary runs fine under Windows. > > Jonathan > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |