> this out of memory failure is caused by inlining. Additionally it has > reasons in growth of debugging sections produced (the same issue in > fact). ...
Thanks for the info, Kai. I was able to mitigate the GPFs compiling with -Os -- Xavi El 22/09/2010 12:22, Kai Tietz escribió: > 2010/9/22 Ruben Van Boxem<vanboxem.ru...@gmail.com>: >> 2010/9/22 Xavi<jara...@gmail.com> >>> >>> >>> >>> When I try to compile wxWidgets 2.8.10 as usual .- >>> >>> mingw32-make -f Makefile.gcc SHARED=1 UNICODE=1 BUILD=release MONOLITHIC=1 >>> g++ -shared -fPIC -o ..\..\lib\gcc_dll\wxmsw28u_gcc_custom.dll ... >>> -mthreads -L..\..\lib\gcc_dll >>> -Wl,--out-implib=..\..\lib\gcc_dll\libwxmsw28u.a ... >>> >>> I get the error .- >>> ld.exe: out of memory allocating 32706688 bytes >>> >> >> This is a known bug in gcc. I could apply the reversal patch (like TDM64 GCC >> does), or make a x64 toolchain that builds 32-bit binaries. This last will >> probably result in huge object files for wxWidgets. What happens if you try >> to build x64 wxWidgets (if you have enough RAM, the link process should >> succeed, but reading the mailing lists, could produce oversized >> binaries...)? How big are the generated binaries? >> >>> >>> or active debug .- >>> mingw32-make -f Makefile.gcc SHARED=1 UNICODE=1 BUILD=debug MONOLITHIC=1 >>> gcc_mswuddll\monodll_laywin.o: could not read symbols: Memory exhausted >>> >>> With mingw-w32-bin_i686-mingw_20100914_sezero.zip runs fine. >> >> The problem is the abovementioned patch/bug in GCC 4.5+ >> >>> >>> ------------------------------------------------------------------ >>> But with this version mingw-w32-bin_i686-mingw_20100914_sezero.zip I have >>> "mysterious" (for me :) GPFs in XP sp3.- >>> >>> Access Violation at location 77c0554a in module msvcrt.dll Reading from >>> location 0000000d. >>> >>> Registers: >>> eax=00411676 ebx=77c2f990 ecx=77c09bc6 edx=00000000 esi=00e5ffa4 >>> edi=00000000 >>> eip=77c0554a esp=00e5fb94 ebp=00000005 iopl=0 nv up ei pl zr na po >>> nc >>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 >>> efl=00010246 >>> >>> Call stack: >>> 77C0554A C:\WINDOWS\system32\msvcrt.dll:77C0554A __NLG_Notify >>> >>> It also happens with gdb, simply turn on break assert .- >>> GNU gdb (GDB) 7.2.50.20100914-cvs >>> This GDB was configured as "i686-w64-mingw32". >>> (gdb) break assert >> >> Can't help you there... >> >> I'm in the process of reviewing my builds, as they can't reporoduce >> themselves, might just be libtool acting up (and have no consequences on >> non-autotools projects). I'll see what I can do to address this issue as >> well. >> >> My original plan was to provide unpatched builds, but it seems there are >> more problems left than I thought... >> >> Ruben > > Hi Rubenvb, > > this out of memory failure is caused by inlining. Additionally it has > reasons in growth of debugging sections produced (the same issue in > fact). To solve this you can use binutils (on a 64-bit OS) build for > host x64. So you can consume much more heap ;) > The real solution for this will be a modification in c++ compiler, and > on the other hand support of not double linking of debugging > information related to linkonce functions. The latter could be handled > in binutils (via .cfi). > > Regards, > Kai > ------------------------------------------------------------------------------ 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
