Plugin compilation issue Ubuntu 13.04

[dmoore]

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

Code Select Expand



-------------- 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?

[Alpha]

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.  I think the solution was to add the -ansi build flag.

[stahta01]

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.  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

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.

[dmoore]

-ansi did the trick. Does that mean that we should be including -ansi in our plugin project template build options?

[Alpha]

Does that mean that we should be including -ansi in our plugin project template build options?

Probably.

[MortenMacFly]

Probably.

I would say yes, too

[stahta01]

-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

When 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.