Re: FYI on my MinGW goals
Am 28.03.2011 20:24, schrieb Guenter Knauf: and that seems to work - it skips the useless testing for *mingw* and sets the right typedef in apr.h, and the warning is then also gone; but not sure if its the right patch ... with this one and all the other recent fixes apr-1.4.x looks now pretty good - only 3 warnings remain now with misc/win32/start.c; I've just build a round with clang to make the issues a bit more clear: http://people.apache.org/~fuankg/mingw/build_w32_msys_clang.txt.gz if whe want to avoid further casts then we probably need to change wchar_t to apr_wchar_t - but that cant be done unconditionally because the presense of apr_wchar_t depends on an unicode_fs define ... Bill, are you in the mood to take a look at this? regarding the DLL prob: when I look into the created Makefile then I dont see any target for a shared library at all - only a target for the static lib exists ... also I think the whole stuff with creating export*.c files + arp.exp is nonsense for MingW - instead we should build with the proper defines for APR_DECLARE* and just link the DLL .. - but unfortunately I am not the right one to fix it this way with my still limited configure knowledge :-( Gün.
Re: FYI on my MinGW goals
On 3/29/2011 11:40 AM, Guenter Knauf wrote: Am 28.03.2011 20:24, schrieb Guenter Knauf: and that seems to work - it skips the useless testing for *mingw* and sets the right typedef in apr.h, and the warning is then also gone; but not sure if its the right patch ... with this one and all the other recent fixes apr-1.4.x looks now pretty good - only 3 warnings remain now with misc/win32/start.c; I've just build a round with clang to make the issues a bit more clear: http://people.apache.org/~fuankg/mingw/build_w32_msys_clang.txt.gz Cool - will review. if whe want to avoid further casts then we probably need to change wchar_t to apr_wchar_t - but that cant be done unconditionally because the presense of apr_wchar_t depends on an unicode_fs define ... Bill, are you in the mood to take a look at this? I don't mind looking at this at all, but it will be a few days before my plate is clear enough to really dig deeply into it. regarding the DLL prob: when I look into the created Makefile then I dont see any target for a shared library at all - only a target for the static lib exists ... Probably a side-effect from libtool and our libtool arguments. Which rev? also I think the whole stuff with creating export*.c files + arp.exp is nonsense for MingW - instead we should build with the proper defines for APR_DECLARE* and just link the DLL .. - but unfortunately I am not the right one to fix it this way with my still limited configure knowledge :-( Of course, you realize much of that same garbage is present on win32 builds (.exp files etc) and we simply need to dodge -installing- these. This is again probably in part an artifact of various libtool flags, consider that the compiler, linker, and libtool authors are rarely on the same page and don't agree on mechanics. The various -export* flags probably affect this.
Re: FYI on my MinGW goals
On 3/29/2011 11:40 AM, Guenter Knauf wrote: Am 28.03.2011 20:24, schrieb Guenter Knauf: and that seems to work - it skips the useless testing for *mingw* and sets the right typedef in apr.h, and the warning is then also gone; but not sure if its the right patch ... with this one and all the other recent fixes apr-1.4.x looks now pretty good - only 3 warnings remain now with misc/win32/start.c; I've just build a round with clang to make the issues a bit more clear: http://people.apache.org/~fuankg/mingw/build_w32_msys_clang.txt.gz if whe want to avoid further casts then we probably need to change wchar_t to apr_wchar_t - but that cant be done unconditionally because the presense of apr_wchar_t depends on an unicode_fs define ... Bill, are you in the mood to take a look at this? Quick observations... clang -E -DHAVE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE -I./include -I/home/Administrator/apr/apr-1.4.x/apr/include/arch/win32 -I./include/arch/unix -I/home/Administrator/apr/apr-1.4.x/apr/include/arch/unix -I/home/Administrator/apr/apr-1.4.x/apr/include exports.c | grep ap_hack_ | sed -e 's/^.*[)]\(.*\);$/\1/' apr.exp In file included from exports.c:12: In file included from D:/MinGW/msys/1.0/home/Administrator/apr/apr-1.4.x/apr/include/apr_allocator.h:25: ./include/apr.h:150:10: fatal error: 'windows.h' file not found #include windows.h ^ 1 error generated. What is *that* about? :) On the wargs, I believe we are replacing that code; I'm creating a VC10 environment for validation right now so I can better understand if the proposed fix for environ allocs is going to be the solution to all of the msvcrXXX flavors. Provided it does, I'll get that committed very shortly.
Re: FYI on my MinGW goals
Hi, Am 30.03.2011 01:14, schrieb William A. Rowe Jr.: 1 error generated. What is *that* about? :) On the wargs, I believe we are replacing that code; I'm creating a VC10environment for validation right now so I can better understand if the proposed fix forenviron allocs is going to be the solution to all of the msvcrXXX flavors. Provided it does, I'll get that committed very shortly. un-important; I saw it ans its because my clang installation is probably wrong; I had to add the mingw includes to CFLAGS, but when export.c is compiled it does only take CPPFLAGS into sccount - thereofre missing headers ... the clang build was just to see the remaining warnings better since clang is much more verbose than gcc and explains more detailed what goes wrong ... Gün.
Re: FYI on my MinGW goals
Am 30.03.2011 01:20, schrieb Guenter Knauf: Hi, Am 30.03.2011 01:14, schrieb William A. Rowe Jr.: 1 error generated. What is *that* about? :) un-important; with un-important I mean here that also with gcc where the includes are fine and pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile. Gün.
Re: FYI on my MinGW goals
On 3/29/2011 6:24 PM, Guenter Knauf wrote: Am 30.03.2011 01:20, schrieb Guenter Knauf: Hi, Am 30.03.2011 01:14, schrieb William A. Rowe Jr.: 1 error generated. What is *that* about? :) un-important; with un-important I mean here that also with gcc where the includes are fine and pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile. This bit looks more important; checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory
Re: FYI on my MinGW goals
On 3/29/2011 6:56 PM, William A. Rowe Jr. wrote: On 3/29/2011 6:24 PM, Guenter Knauf wrote: Am 30.03.2011 01:20, schrieb Guenter Knauf: Hi, Am 30.03.2011 01:14, schrieb William A. Rowe Jr.: 1 error generated. What is *that* about? :) un-important; with un-important I mean here that also with gcc where the includes are fine and pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile. This bit looks more important; checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory One more thought, I am very curious how your results differ if ./buildconf is done on unix rather than in the wild west universe of mingw.
Re: FYI on my MinGW goals
Am 30.03.2011 01:59, schrieb William A. Rowe Jr.: On 3/29/2011 6:56 PM, William A. Rowe Jr. wrote: On 3/29/2011 6:24 PM, Guenter Knauf wrote: Am 30.03.2011 01:20, schrieb Guenter Knauf: Hi, Am 30.03.2011 01:14, schrieb William A. Rowe Jr.: 1 error generated. What is *that* about? :) un-important; with un-important I mean here that also with gcc where the includes are fine and pre-preocessing and compile of export*.c work still no DDL - and no DLL target in Makefile. This bit looks more important; checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory One more thought, I am very curious how your results differ if ./buildconf is done on unix rather than in the wild west universe of mingw. pretty much same ... http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz not a recent one (few days back) but same - no DLLs Gün.
Re: FYI on my MinGW goals
Bill, Am 30.03.2011 02:19, schrieb Guenter Knauf: Am 30.03.2011 01:59, schrieb William A. Rowe Jr.: One more thought, I am very curious how your results differ if ./buildconf is done on unix rather than in the wild west universe of mingw. pretty much same ... http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz not a recent one (few days back) but same - no DLLs just the minute done a fresh build - at same link: http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz and as you can see there now almost all warnings gone, but th eonlyx DDL build is expat; and that result is 100% same as wih MSYS on Windows ... seems that those who did the expat configure knew better than those who did apr/apu ... well, there's a huge scope for enhancement as it seems ... also our configure is at best 'unusual'; f.e. I have already compiled a couple of things successfully on MinGW/MSYS, f.e. such things like bintuils, libcurl, ...; and I did never come over any other configure stuff that depends on Python (yet) ... also I miss a bit good old times 10 years back with the first httpd 2.0 versions when I compiled them on Linux, and just only needed to call ./configure in httpd, and that configure found itself apr, and apr found itself apr-util, and all went without manual interaction ... but seems that these times are gone ... f.e. when I have: base /apr /apr-util why the heck cant apr automatically look for and find ../apr-util if it depends on it? Gün.
Re: FYI on my MinGW goals
Am 30.03.2011 01:56, schrieb William A. Rowe Jr.: This bit looks more important; checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory $ ll bldapr-1.4.x/libtool -rwxr-xr-x 1 Administrator Administratoren 289K Mar 29 15:55 bldapr-1.4.x/libtool so this message seems un-important as well since later on all sources are compiled with libtool ... Gün.
Re: FYI on my MinGW goals
On 3/29/2011 7:46 PM, Guenter Knauf wrote: well, there's a huge scope for enhancement as it seems ... also our configure is at best 'unusual'; f.e. I have already compiled a couple of things successfully on MinGW/MSYS, f.e. such things like bintuils, libcurl, ...; and I did never come over any other configure stuff that depends on Python (yet) ... Point made, but the USER will NEVER do this. They will not invoke buildconf. It's not unreasonable to expect svn based developers to do provision this. A lot easier than a whole toolchain. also I miss a bit good old times 10 years back with the first httpd 2.0 versions when I compiled them on Linux, and just only needed to call ./configure in httpd, and that configure found itself apr, and apr found itself apr-util, and all went without manual interaction ... but seems that these times are gone ... I think maybe you are raising an httpd issue, then, so perhaps that's not on topic for this list? f.e. when I have: base /apr /apr-util why the heck cant apr automatically look for and find ../apr-util if it depends on it? Because apr does not and never did depend on apr-util. apr-util depends on apr. And we won't be shipping apr-util anymore at 2.0 anyways. So perhaps that's the end of that discussion?
Re: FYI on my MinGW goals
On 3/29/2011 7:54 PM, Guenter Knauf wrote: Am 30.03.2011 01:56, schrieb William A. Rowe Jr.: This bit looks more important; checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes grep: /home/Administrator/apr/bldapr-1.4.x/libtool: No such file or directory $ ll bldapr-1.4.x/libtool -rwxr-xr-x 1 Administrator Administratoren 289K Mar 29 15:55 bldapr-1.4.x/libtool so this message seems un-important as well since later on all sources are compiled with libtool ... That grep might possibly be based on manipulating libtool, and since it didn't exist at the right time, the resulting libtool is incorrect?
Re: FYI on my MinGW goals
On 3/29/2011 7:46 PM, Guenter Knauf wrote: just the minute done a fresh build - at same link: http://people.apache.org/~fuankg/mingw/build_w32_cross.txt.gz Apparently, still --silent
Re: FYI on my MinGW goals
Jeff, I found another serious prob with MinGW APR checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 Configuring APR library Platform: i686-pc-mingw32 checking for working mkdir -p... yes APR Version: 1.4.3 . checking size of ino_t... 2 configure: using ino_t for ino_t argh!! And later of course: D:/MinGW/msys/1.0/home/Administrator/apr/apr-1.4.x/apr/file_io/win32/filestat.c: In function 'apr_file_info_get': D:/MinGW/msys/1.0/home/Administrator/apr/apr-1.4.x/apr/file_io/win32/filestat.c:466:19: warning: left shift count = width of type and in apr.h I find: typedef ino_t apr_ino_t; this should be an unsigned __int64 - apr.hw has: typedef apr_uint64_t apr_ino_t; configure.in has at line 1845: ino_t_value=ino_t APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t, $ac_cv_sizeof_long) if test $ac_cv_sizeof_ino_t = 4; then if test $ac_cv_sizeof_long = 4; then ino_t_value=unsigned long else ino_t_value=unsigned int fi fi AC_MSG_NOTICE([using $ino_t_value for ino_t]) how can we properly convince configure to use a 64-bit for MinGW here? I've hacked this: Index: apr/branches/1.4.x/configure.in === --- apr/branches/1.4.x/configure.in (Revision 1085987) +++ apr/branches/1.4.x/configure.in (Arbeitskopie) @@ -1842,15 +1842,24 @@ # releases did. To be correct, apr_ino_t should have been made an # ino64_t as apr_off_t is off64_t, but this can't be done now without # breaking ABI. -ino_t_value=ino_t -APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t, $ac_cv_sizeof_long) -if test $ac_cv_sizeof_ino_t = 4; then -if test $ac_cv_sizeof_long = 4; then -ino_t_value=unsigned long -else -ino_t_value=unsigned int + +# Per OS tuning... +case $host in +*mingw*) +ino_t_value=apr_int64_t +;; +*) +ino_t_value=ino_t +APR_CHECK_SIZEOF_EXTENDED(AC_INCLUDES_DEFAULT, ino_t, $ac_cv_sizeof_long) +if test $ac_cv_sizeof_ino_t = 4; then +if test $ac_cv_sizeof_long = 4; then +ino_t_value=unsigned long +else +ino_t_value=unsigned int +fi fi -fi +;; +esac AC_MSG_NOTICE([using $ino_t_value for ino_t]) # Checks for endianness and that seems to work - it skips the useless testing for *mingw* and sets the right typedef in apr.h, and the warning is then also gone; but not sure if its the right patch ... Gün.
Re: FYI on my MinGW goals
On Mon, Mar 21, 2011 at 1:29 PM, Guenter Knauf fua...@apache.org wrote: Jeff, Am 21.03.2011 14:58, schrieb Jeff Trawick: * ensure it is viable to use the MinGW toolchain to build APR on 1.4.x-trunk for the purpose of (at least) me testing simple fixes and running the test suite and using gcc as another perspective on the Windows code * provide at least some help in the area of reviewing/testing to those willing to do the heavy lifting to make this a properly supported toolchain As part of that I anticipate backporting some fixes for MinGW to 1.4.x/1.5.x to support this, but with no implication that any code line fully/properly supports MinGW. More people will have to continue to help (and perhaps with it in somewhat better shape it will be more practical). how do you call configure? Separately in apr / apr-util, or in apr with some params? when I do it separately in apr-util I still get: Looking for apr source in /home/Administrator/apr-1.4.x/apr Creating include/private/apu_config.h ... Creating configure ... Generating 'make' outputs ... Traceback (most recent call last): File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 230, in module main() File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 135, in main objects, _unused = write_objects(f, legal_deps, h_deps, files) File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 172, in write_objects assert file[-2:] == '.c' AssertionError sadly this had to be debugged again though it was fixed in trunk :( see r1084287 (1.3.x)
Re: FYI on my MinGW goals
Jeff, Am 21.03.2011 14:58, schrieb Jeff Trawick: * ensure it is viable to use the MinGW toolchain to build APR on 1.4.x-trunk for the purpose of (at least) me testing simple fixes and running the test suite and using gcc as another perspective on the Windows code * provide at least some help in the area of reviewing/testing to those willing to do the heavy lifting to make this a properly supported toolchain As part of that I anticipate backporting some fixes for MinGW to 1.4.x/1.5.x to support this, but with no implication that any code line fully/properly supports MinGW. More people will have to continue to help (and perhaps with it in somewhat better shape it will be more practical). how do you call configure? Separately in apr / apr-util, or in apr with some params? when I do it separately in apr-util I still get: Looking for apr source in /home/Administrator/apr-1.4.x/apr Creating include/private/apu_config.h ... Creating configure ... Generating 'make' outputs ... Traceback (most recent call last): File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 230, in module main() File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 135, in main objects, _unused = write_objects(f, legal_deps, h_deps, files) File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 172, in write_objects assert file[-2:] == '.c' AssertionError this is the same prob which I posted some days back already ... the assertion happens because the loop gets 2 times an empty value ... I think I could fix that with copying the whole autostuff from apr-HEAD into apr-1.4.x (though not sure, its been soem days, and was then otherwise busy). Gün.
Re: FYI on my MinGW goals
On Mon, Mar 21, 2011 at 1:29 PM, Guenter Knauf fua...@apache.org wrote: Jeff, Am 21.03.2011 14:58, schrieb Jeff Trawick: * ensure it is viable to use the MinGW toolchain to build APR on 1.4.x-trunk for the purpose of (at least) me testing simple fixes and running the test suite and using gcc as another perspective on the Windows code * provide at least some help in the area of reviewing/testing to those willing to do the heavy lifting to make this a properly supported toolchain As part of that I anticipate backporting some fixes for MinGW to 1.4.x/1.5.x to support this, but with no implication that any code line fully/properly supports MinGW. More people will have to continue to help (and perhaps with it in somewhat better shape it will be more practical). how do you call configure? Separately in apr / apr-util, or in apr with some params? apr trunk: make extraclean ; ./buildconf ./configure --prefix=/c/Users/Trawick/aprinst --without-iconv --with-expat=/c/MinGW --enable-maintainer-mode cfgout 21 ma ke 2stderr (cd test make 2../stderr) ; cat stderr apr-1.4.x: similar, but no --without-iconv or --with-expat apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW), and I haven't tried apr-util yet when I do it separately in apr-util I still get: hopefully I'll get that far before long Looking for apr source in /home/Administrator/apr-1.4.x/apr Creating include/private/apu_config.h ... Creating configure ... Generating 'make' outputs ... Traceback (most recent call last): File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 230, in module main() File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 135, in main objects, _unused = write_objects(f, legal_deps, h_deps, files) File D:/MinGW/msys/1.0/home/Administrator/apr-1.4.x/apr/build/gen-build.py, line 172, in write_objects assert file[-2:] == '.c' AssertionError this is the same prob which I posted some days back already ... the assertion happens because the loop gets 2 times an empty value ... I think I could fix that with copying the whole autostuff from apr-HEAD into apr-1.4.x (though not sure, its been soem days, and was then otherwise busy). Gün.
Re: FYI on my MinGW goals
On 3/21/2011 12:56 PM, Jeff Trawick wrote: apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW), That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib file, perhaps?
Re: FYI on my MinGW goals
On Mon, Mar 21, 2011 at 3:12 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/21/2011 12:56 PM, Jeff Trawick wrote: apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW), That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib file, perhaps? part of it was a missing define to say we're on NT = some value (a commit from you ~1.5 years ago); without it, we skip over the defs in winbase.h) that may be all, but it is mixed in with a bunch of other backports to 1.4.x
Re: FYI on my MinGW goals
Am 21.03.2011 20:51, schrieb Jeff Trawick: On Mon, Mar 21, 2011 at 3:12 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/21/2011 12:56 PM, Jeff Trawick wrote: apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW), That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib file, perhaps? part of it was a missing define to say we're on NT= some value (a commit from you ~1.5 years ago); without it, we skip over the defs in winbase.h) that may be all, but it is mixed in with a bunch of other backports to 1.4.x I wonder how you convince APR to link DLLs at all - for me that doesnt work, I only get a static lib ... what version are you using? I tried with relative new one: $ msysinfo msysinfo-1.3: Send this to the MSYS support list: MSYS 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 unknown; targ=MINGW32 GNU bash, version 3.1.17(1)-release (i686-pc-msys); ENV=.profile GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix gcc.exe (GCC) 4.5.2; targ=MINGW32 and also with mingw32-cross on SuSE 11.1 Linux: $ i686-pc-mingw32-gcc -v Using built-in specs. Target: i686-pc-mingw32 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu --target=i686-pc-mingw32 --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-languages=c,c++,java,fortran,objc,obj-c++ --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-hash-synchronization Thread model: win32 gcc version 4.3.3 (GCC) the build logs look similar, and both build no DLLs ... here are the build logs and the script I used: http://people.apache.org/~fuankg/mingw/ Gün.
Re: FYI on my MinGW goals
On Mon, Mar 21, 2011 at 5:23 PM, Guenter Knauf fua...@apache.org wrote: Am 21.03.2011 20:51, schrieb Jeff Trawick: On Mon, Mar 21, 2011 at 3:12 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/21/2011 12:56 PM, Jeff Trawick wrote: apr 1.4 doesn't link for me (undefined reference to CreateHardLinkW), That's odd, it's in kernel32.dll. A broken kernel32.dll.a/kernel32.lib file, perhaps? part of it was a missing define to say we're on NT= some value (a commit from you ~1.5 years ago); without it, we skip over the defs in winbase.h) that may be all, but it is mixed in with a bunch of other backports to 1.4.x I wonder how you convince APR to link DLLs at all - for me that doesnt work, I only get a static lib ... I don't get DLLs. Check recent activity for bug 46175 for an update about that. what version are you using? I tried with relative new one: $ msysinfo msysinfo-1.3: Send this to the MSYS support list: MSYS 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 unknown; targ=MINGW32 GNU bash, version 3.1.17(1)-release (i686-pc-msys); ENV=.profile GNU Make 3.81This program built for i686-pc-msys; MAKE_MODE=unix gcc.exe (GCC) 4.5.2; targ=MINGW32 I have those versions. and also with mingw32-cross on SuSE 11.1 Linux: $ i686-pc-mingw32-gcc -v Using built-in specs. Target: i686-pc-mingw32 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-suse-linux-gnu --host=x86_64-suse-linux-gnu --target=i686-pc-mingw32 --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-languages=c,c++,java,fortran,objc,obj-c++ --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-hash-synchronization Thread model: win32 gcc version 4.3.3 (GCC) the build logs look similar, and both build no DLLs ... here are the build logs and the script I used: http://people.apache.org/~fuankg/mingw/ Gün.
