From: Ruben V. B. <van...@gm...> - 2010-09-22 20:05:30
Attachments:
dllexportinline.patch
|
Hi, I have uploaded/am uploading a new build of my toolchain. Source is the same (except for gcc, see below), there are some differences in the build steps: - The mingw-w64 crt, gdb and GNU make has been compiled with lto enabled. I hope this solves the ld issue with falsely doubly defined symbols in crtdll2.o while building gmp. - I have deleted the *.la files which were confusing craptools, and hope libtool forgets about them too now. - With regards to this bug report<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601>about the results of this patch <http://gcc.gnu.org/viewcvs?view=revision&revision=147799>, I did some experimenting of my own; attached is a semi-reversal of the patch whiich causes problems in vanilla GCC 4.5. I would like your thoughts on this, because clearly GCC people need some of it for ARM ABI stuff (see link for heated discussion). I have compiled wxWidgets 2.8.11 with and without my patch applied, and my patch solves the size issue as far as I can see. Please test this build Xavi, and see if there are any unforeseen problems. Heck, My half-***ed patch might as well do nothing special... but I thought it was worth a try. I tried to reform it so that only dllexport'd functions are "emitted", and inline dllexprt'd functions are left alone (expected behavior as I can make up from the bug report). - gcc, binutils, gdb are compiled with --disable-nls now because everyone else does that. - gcc is compiled with --enable-fully-dynamic-string and --disable-win32-registry (forgot those before :s) Also, both the 32 and 64-bit build script is included, and in contrast to the old one, these should work now. Put a 32-bit toolchain in the front of PATH when using "buildmingw32.sh", and vice versa for 64-bit building. Uploading now, will take another hour or so for it to complete. Let's hope this one can reproduce itself :) Ruben |
From: Xavi <ja...@gm...> - 2010-09-23 03:54:05
|
Thanks Ruben, It compile wxWidgets (release and debug) as usual, only don't produce debugging information '-g' or is wrong. Also I don't have GPFs [Access Violation at location 77c0554a] compiled with the usual optimizations. -- Xavi El 22/09/2010 22:05, Ruben Van Boxem escribió: > Hi, > > I have uploaded/am uploading a new build of my toolchain. Source is the same (except for gcc, see below), there are some > differences in the build steps: > > - The mingw-w64 crt, gdb and GNU make has been compiled with lto enabled. I hope this solves the ld issue with falsely doubly > defined symbols in crtdll2.o while building gmp. > - I have deleted the *.la files which were confusing craptools, and hope libtool forgets about them too now. > - With regards to this bug report <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601> about the results of this patch > <http://gcc.gnu.org/viewcvs?view=revision&revision=147799>, I did some experimenting of my own; attached is a semi-reversal of > the patch whiich causes problems in vanilla GCC 4.5. I would like your thoughts on this, because clearly GCC people need some of > it for ARM ABI stuff (see link for heated discussion). I have compiled wxWidgets 2.8.11 with and without my patch applied, and > my patch solves the size issue as far as I can see. Please test this build Xavi, and see if there are any unforeseen problems. > Heck, My half-***ed patch might as well do nothing special... but I thought it was worth a try. I tried to reform it so that > only dllexport'd functions are "emitted", and inline dllexprt'd functions are left alone (expected behavior as I can make up > from the bug report). > - gcc, binutils, gdb are compiled with --disable-nls now because everyone else does that. > - gcc is compiled with --enable-fully-dynamic-string and --disable-win32-registry (forgot those before :s) > > Also, both the 32 and 64-bit build script is included, and in contrast to the old one, these should work now. Put a 32-bit > toolchain in the front of PATH when using "buildmingw32.sh", and vice versa for 64-bit building. > > Uploading now, will take another hour or so for it to complete. Let's hope this one can reproduce itself :) > > Ruben |
From: Xavi <ja...@gm...> - 2010-09-25 11:34:56
|
Hi Ruben, Do not need configure --enable-libstdcxx-debug? -- Xavi |