I don't know if this is just a problem with my launchpad recipe (see https://code.launchpad.net/~damien-moore/+recipe/codeblocks-daily) but I suspect not.
System is Ubuntu 13.10, i386, wx-2.8.12, gcc4.6.3
With trunk installed (rev 9404), create a CB plugin using the wizard, then build I get
-------------- Build: default in test (compiler: GNU GCC Compiler)---------------
g++ -I/usr/include/codeblocks -I/usr/include/codeblocks/tinyxml -I/usr/include/codeblocks/scripting/include -I/usr/include/codeblocks/scripting/bindings -I/usr/include/codeblocks/scripting/sqplus -I/usr/include/codeblocks/wxscintilla/include -I/usr/lib/i386-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -g -c src/cbplugin/test/test.cpp -o .objs/test.o
In file included from /usr/include/codeblocks/sdk_common.h:43:0,
from /usr/include/codeblocks/sdk_precomp.h:13,
from /usr/include/codeblocks/sdk.h:17,
from src/cbplugin/test/test.cpp:1:
/usr/include/codeblocks/prep.h:221:16: error: expected unqualified-id before numeric constant
/usr/include/codeblocks/prep.h:227:16: error: expected unqualified-id before numeric constant
Process terminated with status 1 (0 minute(s), 5 second(s))
2 error(s), 0 warning(s) (0 minute(s), 5 second(s))
To get it to build, I have to #undef linux and #undef unix at the top of test.cpp (the plugin implementation)
Searching I saw this issue came up a year or two back and was blamed on something screwy with system headers. Is that right?
Quote from: dmoore on October 20, 2013, 05:56:47 AM
Searching I saw this issue came up a year or two back and was blamed on something screwy with system headers. Is that right?
Yes, that was it (http://forums.next.codeblocks.org/index.php/topic,17986.0.html). I think the solution was to add the
-ansi build flag.
Quote from: Alpha on October 20, 2013, 06:23:52 AM
Quote from: dmoore on October 20, 2013, 05:56:47 AM
Searching I saw this issue came up a year or two back and was blamed on something screwy with system headers. Is that right?
Yes, that was it (http://forums.next.codeblocks.org/index.php/topic,17986.0.html). I think the solution was to add the -ansi build flag.
Or maybe this "Well it turned out to be presence of C++ comments in C file which caused that build failure."
http://forums.next.codeblocks.org/index.php/topic,17986.msg123202.html#msg123202 (http://forums.next.codeblocks.org/index.php/topic,17986.msg123202.html#msg123202)
Edit: After re-reading they added the "ansi" option and had to fix C++ comments in a C file to get the code to compile.
Tim S.
-ansi did the trick. Does that mean that we should be including -ansi in our plugin project template build options?
Quote from: dmoore on October 20, 2013, 07:11:45 AM
Does that mean that we should be including -ansi in our plugin project template build options?
Probably.
Quote from: dmoore on October 20, 2013, 07:11:45 AM
-ansi did the trick. Does that mean that we should be including -ansi in our plugin project template build options?
Might wish to verify that -std is NOT better (this assumes it works as well) before adding to project template.
From http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros (http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros)
QuoteWhen the -ansi option, or any -std option that requests strict conformance, is given to the compiler, all the system-specific predefined macros outside the reserved namespace are suppressed. The parallel macros, inside the reserved namespace, remain defined.
Tim S.