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
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
------------------------------------------------------------------------------
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
