some changes coming in the nightly builds :
- will use wx286
- will use MinGW 4.2.1
- will now be build in a virtual machine [Xp in OpenSuse10.3 or OpenSuse 10.2] instead of native windows
so everyone who knows how to get rid of the new warnings we get in windows with MinGW 4.2.1 feel free to post here below on how to solve them
[hint hint : an interesting one to solve is propgrid.h]
The problem with "propgrid.h" are the multiline string constants taht are no loanger allowed afaik.
In gcc4.2 a warning is generated in gcc4.3 its an error and compiling breaks.
I don't find a compiler- (or preprocessor-) switch to change this behaviour.
So the only (and of course the clean way) is to patch "propgrid.h" and turn the linebraks in the string to "\n", or to upgrade wxpropgrid, what would lead to other (more difficult) problems with wxSmith-code, if I remember a post from byo right.
In the actual version of "propgrid.h" the first lines that lead to this warning look as followed:
"Registers Python type/class to property mapping.\n\nfactory: Property builder function/class."
instead of
"""\
Registers Python type/class to property mapping.
factory: Property builder function/class.
"""
By the way which version of MinGW 4.2.1 is to be used ?
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
The annoying warnings about deprecated string-conversions can be stopped with the flag "-Wwrite-strings" .
For the wxWidgets headers, you'll have to add -Wno-attributes to the compile-time options until it's fixed upstream.
For the "deprecated conversion from string constant to..." errors, you can either add "-Wno-write-strings" to the compile-time options or fix the warning by making functions accept char const* (or the equivalent const char*) instead of just char*. The vast majority of these errors turned up in non-C::B-original code, so my patch uses -Wno-write-strings for those and fixes the single instance in C::B-original code (Append() in AutoBuffer in filemanager.h).
For the fun stuff in wxPropertyGrid, it appears that the preprocessor no longer entirely skips code within conditionals that evaluate to false; it's at least trying to tokenize the Python code and failing. Only fix is to remove the offending bits; I chose to just get rid of the entire SWIG section, since we don't use it.
In Editor.cxx and ScintillaBase.cxx from Scintilla, the fix is to add another set of curly brackets "{}" for correctness around all the zero initializers.
The attached patch is against r4566; it successfully compiles (with no errors or warnings) and runs with both GCC 3.4.5 and 4.2.1-dw2-2.
EDIT:
I also spotted another no-no in AutoBuffer in filemanager.h: using a std::auto_ptr to bind an array (see here (http://www.devx.com/tips/Tip/12998) and here (http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=158&rl=1)). It happens to work for now in GCC using simple objects, but it is undefined in ISO-C++ (the array is freed with delete instead of delete[]).
[attachment deleted by admin]
QuoteFor the wxWidgets headers, you'll have to add -Wno-attributes to the compile-time options until it's fixed upstream.
This had already been done, every windows cbp of CB includes a project build script.
Quotewarnings about deprecated string-conversion
I think we should solve those correctly and not suppress, assuming this would become errors in GCC4.3.
My builds will be dw2 based.
Quote from: killerbot on October 28, 2007, 09:55:44 PM
I think we should solve those correctly and not suppress, assuming this would become errors in GCC4.3.
I can come up with a patch for this if you like, but if you ever want to update the sources from upstream then all my work would magically disappear...
well , I always upgrade wxFlatNotebook (@Eran : if you are reading this, did you already to solve this warning issue, and is it save to sync to your latest svn state since i was planning to upgrade but haven't looked at your latest source for a while now??)
If for the other the changes are small (haven't looked at them yet), then we should go for it.
EDIT : in our source tree I have adjusted the code to get rid of the warnings, basically adding some const's and 1 time casting away the const :-(
FYI:
I am working on back porting the changes in wxPropertyGrid 1.2.9 headers for SWIG multi-line strings to Code::Blocks.
Tim S
I repeat myself:
Quote from: jens on October 28, 2007, 05:23:05 PM
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
The patch fixes the multiline problems, and "progrid.h" and "manager.h" compile without a warning.
It is
not a supression of warnings like the
-Wwrite-strings (at least under linux there is no "-Wno-write"-strings documented).
I have merged your patch Jens.
@Tim : interesting to see the backport, then we have what the future might bring.
@TDragon : preferred Jens' solution for the moment, code looks more like it was before then
C::B complains about this line in wxflatnotebook's popup_dlg.cpp
img.SetAlpha((unsigned char*)signpost_alpha, true);
Edit: The error is still needs fixed, spoke too soon.
sdk\wxFlatNotebook/libwxflatnotebook.a(popup_dlg.o):F:/SourceCode/Projects/IDEs/CodeBlocks/codeblocks/src/sdk/wxFlatNotebook/src/wxFlatNotebook/popup_dlg.cpp:187: undefined reference to `signpost_alpha
Note, the file popup_dlg.cpp also has formatting issues related to linefeeds.
( The formatting might be caused by my SVN Client testing TortoiseSVN Beta)
Tim S
How do I setup MINGW 4.2.1?
Jan
jens:Quote from: jens on October 28, 2007, 11:06:08 PM
... (at least under linux there is no "-Wno-write"-strings documented).
Quote from: GCC 4.2.1 Manual
Each of these specific warning options also has a negative form beginning `-Wno-' to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default.
...
-Wwrite-strings
When compiling C, give string constants the type const char[length] so that copying the address of one into a non-const char * pointer will get a warning; when compiling C++, warn about the deprecated conversion from string literals to char *. This warning, by default, is enabled for C++ programs. These warnings will help you find at compile time code that can try to write into a string constant, but only if you have been very careful about using const in declarations and prototypes. Otherwise, it will just be a nuisance; this is why we did not make -Wall request these warnings.
-Wwrite-strings doesn't turn off the warnings, it enables them (i.e., has no effect when compiling C++). Try it yourself.
killerbot:Handle the wxPG files however you like; none of the code between the #ifdef SWIG conditionals is being used anyway. I'd like to point out that casting const away is almost never a good idea; I'm taking a closer look at the code now.
Quote from: TDragon on October 29, 2007, 12:21:34 AM
jens:
Quote from: jens on October 28, 2007, 11:06:08 PM
... (at least under linux there is no "-Wno-write"-strings documented).
Quote from: GCC 4.2.1 Manual
Each of these specific warning options also has a negative form beginning `-Wno-' to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default.
...
-Wwrite-strings
When compiling C, give string constants the type const char[length] so that copying the address of one into a non-const char * pointer will get a warning; when compiling C++, warn about the deprecated conversion from string literals to char *. This warning, by default, is enabled for C++ programs. These warnings will help you find at compile time code that can try to write into a string constant, but only if you have been very careful about using const in declarations and prototypes. Otherwise, it will just be a nuisance; this is why we did not make -Wall request these warnings.
-Wwrite-strings doesn't turn off the warnings, it enables them (i.e., has no effect when compiling C++). Try it yourself.
You are right of course. :oops:
Thank you for correcting me !
Quote from: jens on October 28, 2007, 05:23:05 PM
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
It could be useful to submit your patch to the propgrid tracker:
http://sourceforge.net/tracker/?group_id=133406
Quote from: Steven 'lazalong' on October 29, 2007, 02:50:42 AM
Quote from: jens on October 28, 2007, 05:23:05 PM
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
It could be useful to submit your patch to the propgrid tracker:
http://sourceforge.net/tracker/?group_id=133406
Why, since it has already been applied to SVN?
Tim S
Last successful build is with SVN 4555.
make clean;make stops with the following error:
Since then I get the following error with all susequent SVNs
/bin/sh ../../libtool --tag=CXX --mode=link g++ -O2 -ffast-math -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -o codeblocks -L/opt/gnome/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lfreetype -lz -lfontconfig -lexpat -lglitz -lm -lpng12 -lXrender -lX11 -lpthread -lXau -lXdmcp app.o appglobals.o compilersettingsdlg.o crashhandler.o dlgabout.o dlgaboutplugin.o environmentsettingsdlg.o infopane.o ipc.o main.o prefix.o printdlg.o scriptconsole.o scriptingsettingsdlg.o splashscreen.o startherepage.o -LwxAUI -lwxaui -L../sdk -lcodeblocks -L/usr/local/lib -pthread -lwx_gtk2u-2.8 -lpthread -ldl
g++ -O2 -ffast-math -g -O2 -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -o .libs/codeblocks app.o appglobals.o compilersettingsdlg.o crashhandler.o dlgabout.o dlgaboutplugin.o environmentsettingsdlg.o infopane.o ipc.o main.o prefix.o printdlg.o scriptconsole.o scriptingsettingsdlg.o splashscreen.o startherepage.o -pthread -L/opt/gnome/lib -L/usr/src/codeblocks/src/src/wxAUI /usr/src/codeblocks/src/src/wxAUI/.libs/libwxaui.a /opt/gnome/lib/libgtk-x11-2.0.so /opt/gnome/lib/libgdk-x11-2.0.so /opt/gnome/lib/libatk-1.0.so /opt/gnome/lib/libgdk_pixbuf-2.0.so /opt/gnome/lib/libpangocairo-1.0.so /opt/gnome/lib/libpangoft2-1.0.so /opt/gnome/lib/libpango-1.0.so /usr/lib/libcairo.so /opt/gnome/lib/libgobject-2.0.so /opt/gnome/lib/libgmodule-2.0.so /opt/gnome/lib/libglib-2.0.so -lrt /usr/lib/libfontconfig.so /usr/lib/libfreetype.so -lexpat /usr/lib/libglitz.so /usr/lib/libpng12.so -lm -lz /usr/lib/libXrender.so /usr/lib/libX11.so /usr/lib/libXau.so /usr/lib/libXdmcp.so -L/usr/src/codeblocks/src/sdk /usr/src/codeblocks/src/sdk/.libs/libcodeblocks.so -L/usr/local/lib -lwx_gtk2u-2.8 -lpthread -ldl
/usr/src/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `signpost_alpha'
collect2: ld returned 1 exit status
make[3]: *** [codeblocks] Error 1
make[3]: Leaving directory `/usr/src/codeblocks/src/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/codeblocks/src/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/codeblocks/src'
Suse 10.2 2.8.4
I have not changed any of the command line options
Probably just a bad revision, wait till the next revision and try again ... it worked for me once.
Also have any of the devs tried compiling in Code::Blocks under GNU/Linux with GCC 4.2.1? because a few people (including myself) are having problems with incremental builds ... as in they don't work at all, a full rebuild is always forced when you 'build'.
Quote from: stahta01 on October 29, 2007, 02:54:56 AM
Quote from: Steven 'lazalong' on October 29, 2007, 02:50:42 AM
Quote from: jens on October 28, 2007, 05:23:05 PM
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
It could be useful to submit your patch to the propgrid tracker:
http://sourceforge.net/tracker/?group_id=133406
Why, since it has already been applied to SVN?
Tim S
@Tim:
He means the tracking system of wxPropertyGrid.
@lazalong:
It's fixed in newer revision(s) that the one used by codeblocks.
Quote from: jens on October 29, 2007, 05:42:19 AM
Quote from: stahta01 on October 29, 2007, 02:54:56 AM
Quote from: Steven 'lazalong' on October 29, 2007, 02:50:42 AM
Quote from: jens on October 28, 2007, 05:23:05 PM
I've created a patch for "propgrid.h" and "manager.h" : http://jens.lody.name/debian/patches/propgrid.patch (http://jens.lody.name/debian/patches/propgrid.patch)
It could be useful to submit your patch to the propgrid tracker:
http://sourceforge.net/tracker/?group_id=133406
Why, since it has already been applied to SVN?
Tim S
@Tim:
He means the tracking system of wxPropertyGrid.
@lazalong:
It's fixed in newer revision(s) that the one used by codeblocks.
Yeah, but since the problem does NOT exist in 1.2.9 release; all we would do is annoy the wxPropertyGrid manager.
Tim S
Quote from: tvaster on October 29, 2007, 03:25:47 AM
/usr/src/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `signpost_alpha'
Try this patch
Index: src/sdk/wxFlatNotebook/src/wxFlatNotebook/fnb_resources.cpp
===================================================================
--- src/sdk/wxFlatNotebook/src/wxFlatNotebook/fnb_resources.cpp (revision 4572)
+++ src/sdk/wxFlatNotebook/src/wxFlatNotebook/fnb_resources.cpp (working copy)
@@ -136,7 +136,7 @@
" ",
" "
};
-const unsigned char signpost_alpha[]={
+unsigned char signpost_alpha[]={
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 7, 174, 240, 238, 148, 0, 0, 0, 0, 0, 0, 0,
Someone, appears to have added to many const.
FYI: You do realize SVN is broken, Right?
It errors out a little farther after the patch.
Tim S
I added the const, but on linux everything builded fine for me, just tried on windows same issue, but why should it not be const ??
[now the warning will be back :-( ] It is used once at a place where I cast away the const, but as fas as I can't tell from the wx doc, it seems the argument will not be changed by the wxImage method [not even delete since 2e arg is true]
Have undo-ed that const in the meantime.
[I wonder why make or gcc apparently is not working correctly, since for some it breaks compilation, for others it don't]
Quote from: killerbot on October 29, 2007, 07:57:02 AM
I added the const, but on linux everything builded fine for me, just tried on windows same issue, but why should it not be const ??
[now the warning will be back :-( ] It is used once at a place where I cast away the const, but as fas as I can't tell from the wx doc, it seems the argument will not be changed by the wxImage method [not even delete since 2e arg is true]
[I wonder why make or gcc apparently is not working correctly, since for some it breaks compilation, for others it don't]
The "const" was causing an linker error in windows; the correct solution could be somewhere else.
But, removing the const did not cause a compiler warning for me. Using MinGW 4.2 SJLJ
Oops, I just remember I have several warning flags turned off.
Tim S
Quote from: killerbot on October 28, 2007, 09:55:44 PM
This had already been done, every windows cbp of CB includes a project build script.
The script is OK (and cool ;-)) but I'd like to veto the path where it had been put into. Remember that usually you can checkout the C::B C++ sources only using svn.berlios.de/svnroot/repos/codeblocks/src? This won't work now anymore. Why didn't you put this script under src/build_tools ? That would have been the place to do IMHO...?!
With regards, Morten.
Byo is the only one using wxPropertyGrid. I think you should just wait for him to finish his update to the most recent version (which has been talked of a few weeks ago). Then wxPropertyGrid will be gone from the Code::Blocks SDK anyway, and possibly the warnings are magically gone too.
Quote from: MortenMacFly on October 29, 2007, 09:21:14 AM
Quote from: killerbot on October 28, 2007, 09:55:44 PM
This had already been done, every windows cbp of CB includes a project build script.
The script is OK (and cool ;-)) but I'd like to veto the path where it had been put into. Remember that usually you can checkout the C::B C++ sources only using svn.berlios.de/svnroot/repos/codeblocks/src? This won't work now anymore. Why didn't you put this script under src/build_tools ? That would have been the place to do IMHO...?!
With regards, Morten.
for no reason, you could put it in src (next to the main cbp), it is not actually a build tool. It is there temporarily untill the wx guys clean up their ...
Quote from: killerbot on October 29, 2007, 09:54:54 AM
for no reason, you could put it in src (next to the main cbp), it is not actually a build tool. It is there temporarily untill the wx guys clean up their ...
Just remove the script file. Following attached script would do the job for us.
[[if (PLATFORM == PLATFORM_MSW && (GetCompilerFactory().GetCompilerVersionString(_T("gcc")) >= _T("4.2.0"))) print(_T("-Wno-attributes"));]]Add the above line to Project > Build options > Compiler settings > Other options section as a compiler option. It would get expanded during building and will remain attached to the Project file.
Please Note: Don't break the line into two or more. It simply won't work. :)
Quote from: killerbot on October 29, 2007, 09:54:54 AM
It is there temporarily untill the wx guys clean up their ...
Quote from: thomas on October 29, 2007, 09:26:35 AM
Then wxPropertyGrid will be gone from the Code::Blocks SDK anyway, and possibly the warnings are magically gone too.
Oh - ok... so I do the change locally only until it's removed from SVN again - I thought this would be a permanent thing...
Quote from: Biplab on October 29, 2007, 10:03:03 AM
Quote from: killerbot on October 29, 2007, 09:54:54 AM
for no reason, you could put it in src (next to the main cbp), it is not actually a build tool. It is there temporarily untill the wx guys clean up their ...
Just remove the script file. Following attached script would do the job for us.
[[if (PLATFORM == PLATFORM_MSW && (GetCompilerFactory().GetCompilerVersionString(_T("gcc")) >= _T("4.2.0"))) print(_T("-Wno-attributes"));]]
Add the above line to Project > Build options > Compiler settings > Other options section as a compiler option. It would get expanded during building and will remain attached to the Project file.
Please Note: Don't break the line into two or more. It simply won't work. :)
hey you cracked it to put it into the cbp ;-) , I have tried but failed ;-)
However, looking back on this, I think it is better to have it in a script, otherwise you have to make sure every plug-in also has the correct pseudo script in place ...
Quote from: killerbot on October 29, 2007, 10:07:44 AM
hey you cracked it to put it into the cbp ;-) , I have tried but failed ;-)
However, looking back on this, I think it is better to have it in a script, otherwise you have to make sure every plug-in also has the correct pseudo script in place ...
As you wish. :)
Can you please move that script to a location where it does not break the build?
I am checking out trunk/src rather than trunk because I am not interested in 200 MB of additional junk (web pages, art assets, documentation) that I will never use during development and which slows down every update and commit.
I think one should be able to assume that trunk/src is self-contained and does not require anything outside.
EDIT: I see Martin already asked for that too, didn't see, sorry.
ok, will move it into src
for some reason, CBgames don't compile on my machine with MINGW.3.4.5
It fails because when it includes tinyxml.h, that one can find tinystr.h
On my MinGW 4.2.1 it does build.
Why is this so inconsistent, have done a rebuild all. Or are those pch's biting me again ??
Quote from: killerbot on October 29, 2007, 10:54:06 AM
Why is this so inconsistent, have done a rebuild all. Or are those pch's biting me again ??
Nope - there were simply some missing includes in the project files. I'll update the project files for Windows accordingly (had the same issue).
Quote from: killerbot on October 29, 2007, 10:54:06 AM
for some reason, CBgames don't compile on my machine with MINGW.3.4.5
BTW: I can also do the update with the script path. I have done it on my machine anyways... shall I???
Quote from: MortenMacFly on October 29, 2007, 11:04:10 AM
Quote from: killerbot on October 29, 2007, 10:54:06 AM
Why is this so inconsistent, have done a rebuild all. Or are those pch's biting me again ??
Nope - there were simply some missing includes in the project files. I'll update the project files for Windows accordingly (had the same issue).
but they should be missing on 4.2.1 also ?? And there I could build ok.
Thanks for sorting this out Martin, kind of hectic here in the office
Quote from: MortenMacFly on October 29, 2007, 11:11:05 AM
Quote from: killerbot on October 29, 2007, 10:54:06 AM
for some reason, CBgames don't compile on my machine with MINGW.3.4.5
BTW: I can also do the update with the script path. I have done it on my machine anyways... shall I???
That would be very nice, don'tforget the contrib plugins ;-)
Quote from: killerbot on October 29, 2007, 11:12:15 AM
That would be very nice, don'tforget the contrib plugins ;-)
Massive CBP update and script moving done. I hope it'll work again now. Could any MinGW 3.4.5 user please give it a try? I (hopefully) didn't forget anything...
Quote from: MortenMacFly on October 29, 2007, 11:23:30 AM
Quote from: killerbot on October 29, 2007, 11:12:15 AM
That would be very nice, don'tforget the contrib plugins ;-)
Massive CBP update and script moving done. I hope it'll work again now. Could any MinGW 3.4.5 user please give it a try? I (hopefully) didn't forget anything...
I just compiled CodeBlocks.cbp OK using MinGW GCC 3.4.5.
Tim S
me too (and contribs) : ok
Patch submitted to wxWidgets that helps to reduce warnings in compiling code::blocks
Tim S
http://sourceforge.net/tracker/index.php?func=detail&aid=1822143&group_id=9863&atid=309863
Requires code below to be added to file wx/dlimpexp.h.
/* wx-2.9 introduces new macros for forward declarations, include them
* here for forward compatibility:
GCC warns about using __attribute__ (and also __declspec in mingw32 case) on
forward declarations while MSVC complains about forward declarations without
__declspec for the classes later declared with it, so we need a separate set
of macros for forward declarations to hide this difference:
*/
#if (defined(__WINDOWS__) && defined(__GNUC__))
#define WXDLLIMPEXP_FWD_BASE
#define WXDLLIMPEXP_FWD_NET
#define WXDLLIMPEXP_FWD_CORE
#define WXDLLIMPEXP_FWD_ADV
#define WXDLLIMPEXP_FWD_QA
#define WXDLLIMPEXP_FWD_HTML
#define WXDLLIMPEXP_FWD_GL
#define WXDLLIMPEXP_FWD_XML
#define WXDLLIMPEXP_FWD_XRC
#define WXDLLIMPEXP_FWD_AUI
#define WXDLLIMPEXP_FWD_RICHTEXT
#define WXDLLIMPEXP_FWD_MEDIA
#define WXDLLIMPEXP_FWD_STC
#else
#define WXDLLIMPEXP_FWD_BASE WXDLLIMPEXP_BASE
#define WXDLLIMPEXP_FWD_NET WXDLLIMPEXP_NET
#define WXDLLIMPEXP_FWD_CORE WXDLLIMPEXP_CORE
#define WXDLLIMPEXP_FWD_ADV WXDLLIMPEXP_ADV
#define WXDLLIMPEXP_FWD_QA WXDLLIMPEXP_QA
#define WXDLLIMPEXP_FWD_HTML WXDLLIMPEXP_HTML
#define WXDLLIMPEXP_FWD_GL WXDLLIMPEXP_GL
#define WXDLLIMPEXP_FWD_XML WXDLLIMPEXP_XML
#define WXDLLIMPEXP_FWD_XRC WXDLLIMPEXP_XRC
#define WXDLLIMPEXP_FWD_AUI WXDLLIMPEXP_AUI
#define WXDLLIMPEXP_FWD_RICHTEXT WXDLLIMPEXP_RICHTEXT
#define WXDLLIMPEXP_FWD_MEDIA WXDLLIMPEXP_MEDIA
#define WXDLLIMPEXP_FWD_STC WXDLLIMPEXP_STC
#endif
Patch to SVN Branch 2.8 for above code addition
Index: include/wx/dlimpexp.h
===================================================================
--- include/wx/dlimpexp.h (revision 49512)
+++ include/wx/dlimpexp.h (working copy)
@@ -234,22 +234,42 @@
#define WXDLLEXPORT_DATA WXDLLIMPEXP_DATA_CORE
/* wx-2.9 introduces new macros for forward declarations, include them
- * here for forward compatibility: */
-#define WXDLLIMPEXP_FWD_BASE WXDLLIMPEXP_BASE
-#define WXDLLIMPEXP_FWD_NET WXDLLIMPEXP_NET
-#define WXDLLIMPEXP_FWD_CORE WXDLLIMPEXP_CORE
-#define WXDLLIMPEXP_FWD_ADV WXDLLIMPEXP_ADV
-#define WXDLLIMPEXP_FWD_QA WXDLLIMPEXP_QA
-#define WXDLLIMPEXP_FWD_ODBC WXDLLIMPEXP_ODBC
-#define WXDLLIMPEXP_FWD_DBGRID WXDLLIMPEXP_DBGRID
-#define WXDLLIMPEXP_FWD_HTML WXDLLIMPEXP_HTML
-#define WXDLLIMPEXP_FWD_GL WXDLLIMPEXP_GL
-#define WXDLLIMPEXP_FWD_XML WXDLLIMPEXP_XML
-#define WXDLLIMPEXP_FWD_XRC WXDLLIMPEXP_XRC
-#define WXDLLIMPEXP_FWD_AUI WXDLLIMPEXP_AUI
-#define WXDLLIMPEXP_FWD_RICHTEXT WXDLLIMPEXP_RICHTEXT
-#define WXDLLIMPEXP_FWD_MEDIA WXDLLIMPEXP_MEDIA
-#define WXDLLIMPEXP_FWD_STC WXDLLIMPEXP_STC
+ * here for forward compatibility:
+
+ GCC warns about using __attribute__ (and also __declspec in mingw32 case) on
+ forward declarations while MSVC complains about forward declarations without
+ __declspec for the classes later declared with it, so we need a separate set
+ of macros for forward declarations to hide this difference:
+ */
+#if (defined(__WINDOWS__) && defined(__GNUC__))
+ #define WXDLLIMPEXP_FWD_BASE
+ #define WXDLLIMPEXP_FWD_NET
+ #define WXDLLIMPEXP_FWD_CORE
+ #define WXDLLIMPEXP_FWD_ADV
+ #define WXDLLIMPEXP_FWD_QA
+ #define WXDLLIMPEXP_FWD_HTML
+ #define WXDLLIMPEXP_FWD_GL
+ #define WXDLLIMPEXP_FWD_XML
+ #define WXDLLIMPEXP_FWD_XRC
+ #define WXDLLIMPEXP_FWD_AUI
+ #define WXDLLIMPEXP_FWD_RICHTEXT
+ #define WXDLLIMPEXP_FWD_MEDIA
+ #define WXDLLIMPEXP_FWD_STC
+#else
+ #define WXDLLIMPEXP_FWD_BASE WXDLLIMPEXP_BASE
+ #define WXDLLIMPEXP_FWD_NET WXDLLIMPEXP_NET
+ #define WXDLLIMPEXP_FWD_CORE WXDLLIMPEXP_CORE
+ #define WXDLLIMPEXP_FWD_ADV WXDLLIMPEXP_ADV
+ #define WXDLLIMPEXP_FWD_QA WXDLLIMPEXP_QA
+ #define WXDLLIMPEXP_FWD_HTML WXDLLIMPEXP_HTML
+ #define WXDLLIMPEXP_FWD_GL WXDLLIMPEXP_GL
+ #define WXDLLIMPEXP_FWD_XML WXDLLIMPEXP_XML
+ #define WXDLLIMPEXP_FWD_XRC WXDLLIMPEXP_XRC
+ #define WXDLLIMPEXP_FWD_AUI WXDLLIMPEXP_AUI
+ #define WXDLLIMPEXP_FWD_RICHTEXT WXDLLIMPEXP_RICHTEXT
+ #define WXDLLIMPEXP_FWD_MEDIA WXDLLIMPEXP_MEDIA
+ #define WXDLLIMPEXP_FWD_STC WXDLLIMPEXP_STC
+#endif
#endif /* _WX_DLIMPEXP_H_ */
Quote from: thomas on October 29, 2007, 09:26:35 AM
Byo is the only one using wxPropertyGrid. I think you should just wait for him to finish his update to the most recent version (which has been talked of a few weeks ago). Then wxPropertyGrid will be gone from the Code::Blocks SDK anyway, and possibly the warnings are magically gone too.
Ok, I'll start working on wxPropertyGrid, but it may take a while (over a week in the worst case), don't have much time now.
BYO
well, with the current change those warnings are also gone.
But maybe the latest wxPropertyGrid has a better solution (dunno, since I dunno that code)
Patch to get rid of 6 warnings building C::B project. Note, this patch is NOT MSVC compatible, but should work OK with GCC. Is it worth it to reduce the warnings by 6 for someone to test this under Linux and Mac?
I tested with MinGW GCC 4.2 SJLJ and it compiled OK. The only option I used was "-Wno-write-strings" and I had no warnings. Note, I used a patched wxWidgets 2.8.x.
Tim S
Index: src/include/propgrid/include/wx/propgrid/odcombo.h
===================================================================
--- src/include/propgrid/include/wx/propgrid/odcombo.h (revision 4580)
+++ src/include/propgrid/include/wx/propgrid/odcombo.h (working copy)
@@ -37,8 +37,8 @@
#define wxPGRectContains Contains
#endif
-class WXDLLEXPORT wxTextCtrl;
-class WXDLLEXPORT wxButton;
+class wxTextCtrl;
+class wxButton;
#ifdef WXMAKINGLIB_PROPGRID
#define WXDLLEXPORT_PGODC
Index: src/include/xtra_res.h
===================================================================
--- src/include/xtra_res.h (revision 4580)
+++ src/include/xtra_res.h (working copy)
@@ -10,7 +10,7 @@
#endif
-class WXDLLEXPORT wxXmlResourceHandler;
+class wxXmlResourceHandler;
class wxToolBarAddOnXmlHandler : public wxXmlResourceHandler
{
Quote from: byo on October 29, 2007, 09:46:45 PM
Quote from: thomas on October 29, 2007, 09:26:35 AM
Byo is the only one using wxPropertyGrid. I think you should just wait for him to finish his update to the most recent version (which has been talked of a few weeks ago). Then wxPropertyGrid will be gone from the Code::Blocks SDK anyway, and possibly the warnings are magically gone too.
Ok, I'll start working on wxPropertyGrid, but it may take a while (over a week in the worst case), don't have much time now.
BYO
FYI: They just released a new version of wxPropertyGrid 1.2.10
Tim S
Quote from: killerbot on October 29, 2007, 07:57:02 AM
I added the const, but on linux everything builded fine for me, just tried on windows same issue, but why should it not be const ??
[now the warning will be back :-( ] It is used once at a place where I cast away the const, but as fas as I can't tell from the wx doc, it seems the argument will not be changed by the wxImage method [not even delete since 2e arg is true]
Have undo-ed that const in the meantime.
[I wonder why make or gcc apparently is not working correctly, since for some it breaks compilation, for others it don't]
Hmmm... maybe try including fnb_resources.h from fnb_resources.cpp? The header is where all the variables are declared extern, and I believe this will hint the compiler not to optimize the consts away.
Anyone able to access SVN?
I am having problems, but http://monitor.berlios.de/berlios-status/ looked OK to me.
Tim S
Confirmed, same problem here...connection refused.
Confirmed. SVN access via SVN does not work,
but SVN access via HTTP works.
Now works for me
Quote from: keenblade on October 31, 2007, 08:55:27 PM
Confirmed. SVN access via SVN does not work,
but SVN access via HTTP works.
I agree, SVN access via SVN does not work.
But, while SVN access via HTTP works most of the time; I am having some issues with it also.
Update, SVN access via SVN seems to be working at least a little bit now.
Tim S