FYI: GCC 4.5.0 on Mingw.org

[stahta01]

gcc-4.5.0 is released btw.

http://gcc.gnu.org/

wx compilation still runs out of memory though :S looking on how to fix that atm.

It failed for me on Monolithic DLL build; but, worked on MultiLib DLL build.
Win7 32 Bit

Tim S.

[reckless]

aye the monolithic version simply gets to big for ld to handle :/

multilib works fine though.

i can build cb with the multilibs but i doubt the cb guys would love that option ?

[ollydbg]

i can build cb with the multilibs but i doubt the cb guys would love that option ?

I personally perfer monolithic wxWidget library for Codeblocks.

[reckless]

me 2 tbh.

even better since i can now skip the dependency on the mingw dll would be static linking but so far i had no luck with that 

had a look at the gcc variables and there seems to be some switches for inline code. im gonna have a go at trying them out if i find anything of use ill post back.

[reckless]

i found the bugger using a sbrk port to win32 in binutils its wxmediactrl.o running us out of memory i will try compiling with it disabled hold on.

[thynson]

Hi, all

First, pardon for my poor english.

I have succesfully built wxWidgets2.8.11 with MinGW-W64 GCC 4.5.0 cross compiler.
As gcc 4.5.0 changed its code-generation, now the code dllexport-inline function  shall be generated in object files. However, in the headers of wxWidgets, there are so many dllexport-inline functions, so the object file could be as large as 1MB. In my 2GB RAM laptop, Windows Server 2008 R2, it runs with an end of out of memory exception while linking. So I got a cross compiler from MinGW-W64 project, and start building wxWidgets in Ubuntu Linux with 2GB SWAP space(finally it seems cost about 2.8GB memory for linking). This time I built it successful. And I added --disable-precompile-headers whlie configuration to reduce the size of those object files(cause if precompiled header is used, code for all dllexport-inline functions in header of wx would be generated in EACH OBJECT FILES), and edit the Makefile with flags --no-keep-memory , --reduce-memroy-overheads and --enable-runtime-pseudo-reloc-v2 passed to linker to avoid the situation out of memory and to ensure dll loaded properly.  

By the way I tested this library in code::blocks (windows, of cause), compiling and linking went well. But the program could not run and with a 0x0000000c error. I know this problem could be solved by pass a flag of --enable-runtime-pseudo-reloc-v2 to the linker, and I tested this flags in command line and it works. But I don't know where to add this flag in project build option. I added the flag in 'Compiler settings - other options' tab, but it didn't work. I added the flag in 'Linker setting -Other linker option' box, it didn't work, too. So I think if this, flags couldn't be passed to the linker, is a bug of codeblocks, and plz fix it. Or it's a problem of my codeblocks.
  And I also test 64bit-compiler, but 64-bits linker seems to link resource file wrongly(without .res file, the executable is linked properly, but add a resource file it could not run with an error of 0x0000007d)

[reckless]

if you add it to CXXFLAGS  do it like this CXXFLAGS="-W1,--enable-runtime-pseudo-reloc-v2" to pass it to the linker in case you use LDFLAGS you can get away with this LDFLAGS="-enable-runtime-pseudo-reloc-v2"

the link is indeed  huge memory wise mine bailed out at 2 gig (seems to be the limit for commands in win7 64 bit as anything i tried that went above that crashed).

[idblew]

Wouldn't the solution be to compile/link ld.exe with --large-address-aware ?

PS: Under Windows/MinGW 4.5.0 there is no option called --enable-runtime-pseudo-reloc-v2 only --enable-runtime-pseudo-reloc, is that the same?

UPDATE:  Just tried the above, still doesn't work!

[reckless]

--enable-runtime-pseudo-reloc-v2 is from newer binutils not gcc itself
you can try with --enable-runtime-pseudo-reloc but the v2 had a few more fixes.

not sure but i think the v2 was introduced in version 2.20 of binutils.

heres a patch btw if you prefer v2 to allways be on as default.

--- binutils-2.20/ld/emultempl/pe.em   2009-10-30 15:36:58.000000000 +0100
+++ binutils-2.20/ld/emultempl/pe.em   2009-10-30 15:38:07.000000000 +0100
@@ -161,7 +161,7 @@
 
 fragment <<EOF
   link_info.pei386_auto_import = ${default_auto_import};
-  link_info.pei386_runtime_pseudo_reloc = 1; /* Use by default version 1.  */
+  link_info.pei386_runtime_pseudo_reloc = 2; /* Use by default version 2.  */
 
 #if (PE_DEF_SUBSYSTEM == 9) || (PE_DEF_SUBSYSTEM == 2)
 #if defined TARGET_IS_mipspe || defined TARGET_IS_armpe || defined TARGET_IS_arm_wince_pe
@@ -715,7 +715,7 @@
       link_info.pei386_auto_import = 0;
       break;
     case OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC:
-      link_info.pei386_runtime_pseudo_reloc = 1;
+      link_info.pei386_runtime_pseudo_reloc = 2;
       break;
     case OPTION_DLL_ENABLE_RUNTIME_PSEUDO_RELOC_V1:
       link_info.pei386_runtime_pseudo_reloc = 1;

large adress awareness is just a switch to make the code able to use above the 2 gigabyte limitation it does nothing in itself about the size of the object files (which is the problem here).

[idblew]

I already have 2.20 (see ld.exe -V output below) but don't have the v2 option.

GNU ld (GNU Binutils) 2.20
  Supported emulations:
   i386pe

I'm on Windows Vista (SP2) - perhaps the option isn't available in the pre-compiled package for Windows?!

[reckless]

should be the same for any os

well i was'nt sure it was 2.20 i use 2.20.1 and i have it

im on windows 7 64 bit so should be the same for vista.

gonna have to watch out for patches against gcc-4.5.0 if something turns up ill provide a version with the fixes.

[Loaden]

Hi, all

First, pardon for my poor english.

I have succesfully built wxWidgets2.8.11 with MinGW-W64 GCC 4.5.0 cross compiler.
As gcc 4.5.0 changed its code-generation, now the code dllexport-inline function  shall be generated in object files. However, in the headers of wxWidgets, there are so many dllexport-inline functions, so the object file could be as large as 1MB. In my 2GB RAM laptop, Windows Server 2008 R2, it runs with an end of out of memory exception while linking. So I got a cross compiler from MinGW-W64 project, and start building wxWidgets in Ubuntu Linux with 2GB SWAP space(finally it seems cost about 2.8GB memory for linking). This time I built it successful. And I added --disable-precompile-headers whlie configuration to reduce the size of those object files(cause if precompiled header is used, code for all dllexport-inline functions in header of wx would be generated in EACH OBJECT FILES), and edit the Makefile with flags --no-keep-memory , --reduce-memroy-overheads and --enable-runtime-pseudo-reloc-v2 passed to linker to avoid the situation out of memory and to ensure dll loaded properly.  

By the way I tested this library in code::blocks (windows, of cause), compiling and linking went well. But the program could not run and with a 0x0000000c error. I know this problem could be solved by pass a flag of --enable-runtime-pseudo-reloc-v2 to the linker, and I tested this flags in command line and it works. But I don't know where to add this flag in project build option. I added the flag in 'Compiler settings - other options' tab, but it didn't work. I added the flag in 'Linker setting -Other linker option' box, it didn't work, too. So I think if this, flags couldn't be passed to the linker, is a bug of codeblocks, and plz fix it. Or it's a problem of my codeblocks.
  And I also test 64bit-compiler, but 64-bits linker seems to link resource file wrongly(without .res file, the executable is linked properly, but add a resource file it could not run with an error of 0x0000007d)

I find the reason, When linking, we need this option too.
So, add these option BOTH compiler option and linker option.

[Loaden]

Build wxWidgets 2.8.10 failed.

luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodbc32
collect2: ld returned 5 exit status
mingw32-make: *** [..\..\lib\gcc_dll\wxmsw28u.dll] Error 1

config:

Code

# Standard preprocessor flags (common for CC and CXX) 
CPPFLAGS ?= -static-libgcc -static-libstdc++

# Standard linker flags 
LDFLAGS ?= -static-libgcc -static-libstdc++

build:

Code

mingw32-make -f makefile.gcc LDFLAGS=-s SHARED=1 BUILD=release UNICODE=1 MONOLITHIC=1 OFFICIAL_BUILD=1 RUNTIME_LIBS=static

[Loaden]

If we have some DLL module, we can't use -static-libgcc both in DLL and EXE!
So, I change build config to:

Code

mingw32-make -f makefile.gcc CXXFLAGS="-Wl,--enable-auto-import" LDFLAGS="-Wl,--enable-auto-import -s" SHARED=1 BUILD=release UNICODE=1 MONOLITHIC=1 OFFICIAL_BUILD=1 RUNTIME_LIBS=static

And, I build MinGW 4.5 on archlinux. I am test it on XPSP3, it's works well.
DOWNLOAD: http://qp-gcc.googlecode.com/files/mingw4.5.0.7z

And enable header's breakpoint now.

[reckless]

might also be the only option at the moment to crossbuild wxwidgets on linux as theres no way known to increase the stack size for the commandline on windows.

linux does have that option

anyway it builds fine with precompiled wxwidgets so its not to much of a hazzle if you got that.

everything else works rather well i agree