Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

FYI: GCC 4.5.0 on Mingw.org

<< < (5/17) > >>

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.


--- Quote ---GNU ld (GNU Binutils) 2.20
  Supported emulations:
   i386pe

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version