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

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to