FYI: GCC 4.5.0 on Mingw.org

[Loaden]

The current MinGW 4.5 is not recommended!
http://lists-archives.org/mingw-users/16641-gcc-4-5-change-to-generate-code-for-dllexport-d-inline-functions-in-the-dll.html

[ollydbg]

@loaden
reckless has explain this before, see Re: FYI: GCC 4.5.0 on Mingw.org and Re: FYI: GCC 4.5.0 on Mingw.org.

So, till now, is there a reliable mingw 4.5 package we can use to build wxWidgets library?

[reckless]

nothing so far no i need to check the diffs between 4.4.3 and 4.5.0 to see whats changed.

[reckless]

about to release a prebuilt wxwidgets (made with gcc-4.4.3) for my fork of gcc-4.5.0 if anyone wants a dwarf2 build for gcc-4.5.0 loaden could maybe provide one ? as my fork uses sjlj

all options on besides opengl but i can build that to if requested.

includes gdiplus.

[reckless]

ftp://90.184.233.166:21/wxWidgets-prebuilt.lha

use lzarch to uncompress then point codeblocks to where you unpacked it.

[a14331990]

nothing so far no i need to check the diffs between 4.4.3 and 4.5.0 to see whats changed.

I would suggest test wxWidgets with all GCC 4.5 snapshots here,
http://gcc.cybermirror.org/snapshots/
to find when this behavior appear, maybe bisection method is helpful.

[reckless]

whoa had no idea they kept a repository of all the diffs  :shock:

nice find thank you

[a14331990]

I'm trying to find when this behavior appear in GCC svn log
svn log svn://gcc.gnu.org/svn/gcc/trunk > changs.txt
then
delete anything before March 2009 or after May 2010 in changes.txt(because GCC-4.5 snapshots begin at 4.5-20090402 and end at 4.5-20100513)
and filter dllexport related information,
cat changes.txt|grep dllexport > dllexport.txt
finally lookup entries in dllexport.txt in changes.txt for details of these revisions
------------------------------------------------------------------------
r152511 | dannysmith | 2009-10-07 10:57:21 +0800 (Wed, 07 Oct 2009) | 13 lines

   PR target/41512
   * config/i386/winnt.c (i386_pe_determine_dllexport_p): Don't propagate
   dllexport to class members here.
   (i386_pe_determine_dllimport_p): Only check static class data for
   definition.
   (i386_pe_encode_section_info): Don't recheck DECL_DLLIMPORT_P.
   * config/i386/winnt-cxx.c (i386_pe_type_dllimport_p): Only check
   functions for vague linkage.
   (i386_pe_type_dllexport_p): Fix formatting.
   (maybe_add_dllexport) New function.
   (i386_pe_adjust_class_at_definition): Use it to propagate dllexport
   to class members.

------------------------------------------------------------------------

------------------------------------------------------------------------
r149525 | dannysmith | 2009-07-12 14:09:39 +0800 (Sun, 12 Jul 2009) | 4 lines

   * config/i386/winnt.c (i386_pe_determine_dllexport_p): Don't
   dllexport if !TREE_PUBLIC.
   (i386_pe_maybe_record_exported_symbol): Assert TREE_PUBLIC.

------------------------------------------------------------------------

------------------------------------------------------------------------
r147799 | nathan | 2009-05-22 22:57:15 +0800 (Fri, 22 May 2009) | 16 lines

   gcc/
   * tree.c (handle_dll_attribute): Mark dllexport'd inlines as
   non-external.

   gcc/cp
   * decl2.c (decl_needed_p): Consider dllexport'd functions needed.
   * semantics.c (expand_or_defer_fn): Similarly.

   gcc/testsuite/
   * gcc.dg/dll-6.c: New test.
   * gcc.dg/dll-6a.c: Likewise.
   * gcc.dg/dll-7.c: Likewise.
   * gcc.dg/dll-7a.c: Likewise.
   * g++.dg/ext/dllexport2.C: Likewise.
   * g++.dg/ext/dllexport2a.cc: Likewise.

------------------------------------------------------------------------
Please help me test wxWidgets with GCC 4.5 snapshots around the above date.

[a14331990]

Here is a patch to undo the change by nathan at 2009-05-22

Code

--- gcc/tree.c	2010-04-02 00:18:08 +0800 revert some code to gcc-4.5-20090521, don't emit exported inline functions
+++ gcc/tree-2.c	2010-05-14 22:56:44 +0800
@@ -5377,11 +5377,6 @@
       if (*no_add_attrs == false)
         DECL_DLLIMPORT_P (node) = 1;
     }
-  else if (TREE_CODE (node) == FUNCTION_DECL
-	   && DECL_DECLARED_INLINE_P (node))
-    /* An exported function, even if inline, must be emitted.  */
-    DECL_EXTERNAL (node) = 0;
-
   /*  Report error if symbol is not accessible at global scope.  */
   if (!TREE_PUBLIC (node)
       && (TREE_CODE (node) == VAR_DECL
--- gcc/cp/decl2.c	2010-03-24 06:29:54 +0800
+++ gcc/cp/decl2-2.c	2010-05-14 23:00:42 +0800
@@ -1782,10 +1782,6 @@
       || (DECL_ASSEMBLER_NAME_SET_P (decl)
 	  && TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))))
       return true;
-  /* Functions marked "dllexport" must be emitted so that they are
-     visible to other DLLs.  */
-  if (lookup_attribute ("dllexport", DECL_ATTRIBUTES (decl)))
-    return true;
   /* Otherwise, DECL does not need to be emitted -- yet.  A subsequent
      reference to DECL might cause it to be emitted later.  */
   return false;
--- gcc/cp/semantics.c	2010-04-02 02:48:34 +0800
+++ gcc/cp/semantics-2.c	2010-05-14 23:14:04 +0800
@@ -3447,10 +3447,8 @@
 
       /* If the user wants us to keep all inline functions, then mark
 	 this function as needed so that finish_file will make sure to
-	 output it later.  Similarly, all dllexport'd functions must
-	 be emitted; there may be callers in other DLLs.  */
-      if ((flag_keep_inline_functions && DECL_DECLARED_INLINE_P (fn))
-	  || lookup_attribute ("dllexport", DECL_ATTRIBUTES (fn)))
+	 output it later.  */
+      if (flag_keep_inline_functions && DECL_DECLARED_INLINE_P (fn))
 	mark_needed (fn);
     }
 

     But according to infomation here
[Mingw-users] gcc 4.5 change to generate code for dllexport'd inline functions in the DLL
http://lists-archives.org/mingw-users/16635-gcc-4-5-change-to-generate-code-for-dllexport-d-inline-functions-in-the-dll.html

For C DLLs the solution seems simple enough: just don't dllexport inline
functions and no code for them will be generated. But this doesn't work for
C++ DLLs because, AFAIK, all C++ libraries use the same approach for DLL
export, namely they declare the entire classes as being dllexport'd which
inevitably leads to all of its inline functions being dllexport'd as well.

[stahta01]

Bug report on gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601

Edit: Added trial of visibility=hidden

Has anyone tried using "-fvisibility=hidden" option? It Failed for me.
I am trying it now; may know in an hour or two if it helps.
I just read the info on http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes and it says what I am trying wont work; but, it also says the problem does not exist.

After that fails will try "-fvisibility-inlines-hidden" the descriptions sounds like the right fix.
The number of warnings seem to been increased over 100 fold.
I aborted the build it appeared to still be too build of object size.
 
http://gcc.gnu.org/wiki/Visibility

Lastly, there's one other new command line switch: -fvisibility-inlines-hidden. This causes all inlined class member functions to have hidden visibility, causing significant export symbol table size & binary size reductions though not as much as using -fvisibility=hidden. However, -fvisibility-inlines-hidden can be used with no source alterations, unless you need to override it for inlines where address identity is important either for the function itself or any function local static data.

Tim S.

[a14331990]

I have enabled auto-import in ld with this patch.

Code

--- ld/emultempl/pe.em	2009-09-14 19:43:30 +0800
+++ ld/emultempl/pe.em	2010-01-29 10:49:20 +0800
@@ -155,7 +155,7 @@
     default_auto_import=1
     ;;
   *)
-    default_auto_import=-1
+    default_auto_import=1
     ;;
 esac
 
@@ -946,7 +946,8 @@
 
 		if (pe_enable_stdcall_fixup == -1)
 		  {
-		    einfo (_("Warning: resolving %s by linking to %s\n"),
+		    if (link_info.pei386_auto_import == -1)
+               info_msg (_("Info: resolving %s by linking to %s (auto-import)\n"),
 			   undef->root.string, cname);
 		    if (! gave_warning_message)
 		      {
@@ -973,7 +974,8 @@
 
 		if (pe_enable_stdcall_fixup == -1)
 		  {
-		    einfo (_("Warning: resolving %s by linking to %s\n"),
+		    if (link_info.pei386_auto_import == -1)
+               info_msg (_("Info: resolving %s by linking to %s (auto-import)\n"),
 			   undef->root.string, sym->root.string);
 		    if (! gave_warning_message)
 		      {

It is supposed to be used together with the patch in my previous reply.
     In this way, gcc 4.5 don't emit exported inline functions and ld can auto-import symbols.
     I'm testing wxMSW 2.8.11 now with this config

Code

...
SHARED ?= 1
...
UNICODE ?= 1
...
BUILD ?= release
...
MONOLITHIC ?= 1
...
OFFICIAL_BUILD ?= 1
...

    the object files generated are small, 100k per one, don't know linking will work or not, my machine is slow.

[a14331990]

Success!
The build generated small object files of size 61.5MB in total
and can produce the dll
wxmsw28u_gcc.dll
of size 9.84MB.
    This dll is woking, I tested it with demos/life successfully.

[ollydbg]

Success!
The build generate small object files of size 61.5MB in total
and can produce the dll
wxmsw28u_gcc.dll
of size 9.84MB.
    This dll is woking, I tested it with demos/life successfully.

Nice!!
So, it seems after applying your patch, it is a really workable GCC mingw 4.5.

[a14331990]

First, some credits,
the patch about auto-import comes from this post by Dave Korn and slightly modified by me
[PATCH] Silence ld auto-import warnings for pe-i386.
http://sourceware.org/ml/binutils/2009-02/msg00341.html
and the patch about dllexport is just a removal of nathan's code.
r147799 | nathan | 2009-05-22 22:57:15 +0800 (Fri, 22 May 2009) | 16 lines

   gcc/
   * tree.c (handle_dll_attribute): Mark dllexport'd inlines as
   non-external.

   gcc/cp
   * decl2.c (decl_needed_p): Consider dllexport'd functions needed.
   * semantics.c (expand_or_defer_fn): Similarly.

   gcc/testsuite/
   * gcc.dg/dll-6.c: New test.
   * gcc.dg/dll-6a.c: Likewise.
   * gcc.dg/dll-7.c: Likewise.
   * gcc.dg/dll-7a.c: Likewise.
   * g++.dg/ext/dllexport2.C: Likewise.
   * g++.dg/ext/dllexport2a.cc: Likewise.
    I have just built codeblocks r6216 (gcc-4.5,wxmsw 2.8.11), startup ok, cannot open code editor (maybe too slow), I then check another build of codeblocks r6216 (gcc-4.4,wxmsw 2.8.11), same problem. I think I should try wxmsw 2.8.10.
    Update: I close many programs and codeblocks works fine now.
 

[reckless]

youre a god thank you very much