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

[Noob] Compilation problem on the nightly build on Linux

(1/3) > >>

TSalm:
Hi all,

I'm on a Linux plateform.

In the file 'src/include/prep.h', this code

--- Code: ---    const bool windows = (id == platform_windows);
    const bool macos   = (id == platform_macos);
    const bool linux   = (id == platform_linux);
    const bool freebsd = (id == platform_freebsd);
    const bool netbsd  = (id == platform_netbsd);
    const bool openbsd = (id == platform_openbsd);
    const bool unix    = (linux | freebsd | netbsd | openbsd);
--- End code ---

product the error :

--- Code: --- g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/include -I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA -I../../../src/include/wxscintilla/include -I../../../src/include -I../../../src/include/tinyxml -O2 -ffast-math -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT tinyxmlparser.lo -MD -MP -MF .deps/tinyxmlparser.Tpo -c tinyxmlparser.cpp  -fPIC -DPIC -o .libs/tinyxmlparser.o
if /bin/bash ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/include -I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA   -I../../../src/include/wxscintilla/include -I../../../src/include -I../../../src/include/tinyxml    -O2 -ffast-math  -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT tinywxuni.lo -MD -MP -MF ".deps/tinywxuni.Tpo" -c -o tinywxuni.lo tinywxuni.cpp; \
        then mv -f ".deps/tinywxuni.Tpo" ".deps/tinywxuni.Plo"; else rm -f ".deps/tinywxuni.Tpo"; exit 1; fi
 g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/include -I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -DNO_GCC_PRAGMA -I../../../src/include/wxscintilla/include -I../../../src/include -I../../../src/include/tinyxml -O2 -ffast-math -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -MT tinywxuni.lo -MD -MP -MF .deps/tinywxuni.Tpo -c tinywxuni.cpp  -fPIC -DPIC -o .libs/tinywxuni.o
../../../src/include/prep.h:59: error: expected unqualified-id before numeric constant
../../../src/include/prep.h:63: error: expected unqualified-id before numeric constant

--- End code ---

If I rename the const 'linux' to '_linux' for example, and 'unix' to '_unix', there's no more problem here (but, consequently, the problem is an other side...).
Really strange, isn't it !?
TIA,

Best regard,
TSalm

Der Meister:
Killerbot already commited a (temporary?) fix for this in revision 3687 but thomas just reverted it in revision 3690. I have no idea why and no idea whether Killerbot's fix really worked or could be used for the future (as it was marked temporary).

mihaim:
I had the same problem compiling the svn tree today. Renamining linux to _linux in prep.h will give later on errors in sdk/configmanager.cpp . I simply renamed linux and unix to linux_a and unix_a in both files and compile was successfull.

diff -Naur trunk/src/include/prep.h trunk-fixed/src/include/prep.h
--- trunk/src/include/prep.h    2007-03-13 01:18:27.000000000 +0200
+++ trunk-fixed/src/include/prep.h      2007-03-13 00:42:57.000000000 +0200
@@ -56,11 +56,11 @@

     const bool windows = (id == platform_windows);
     const bool macos   = (id == platform_macos);
-    const bool linux   = (id == platform_linux);
+    const bool linux_a   = (id == platform_linux);
     const bool freebsd = (id == platform_freebsd);
     const bool netbsd  = (id == platform_netbsd);
     const bool openbsd = (id == platform_openbsd);
-    const bool unix    = (linux | freebsd | netbsd | openbsd);
+    const bool unix_a    = (linux_a | freebsd | netbsd | openbsd);

     const int bits = 8*sizeof(void*);

diff -Naur trunk/src/sdk/configmanager.cpp trunk-fixed/src/sdk/configmanager.cpp
--- trunk/src/sdk/configmanager.cpp     2007-03-13 01:14:29.000000000 +0200
+++ trunk-fixed/src/sdk/configmanager.cpp       2007-03-13 00:59:16.000000000 +0200
@@ -243,11 +243,11 @@

     if(platform::windows)
         info.append(_T("\n\t Windows "));
-    if(platform::linux)
+    if(platform::linux_a)
         info.append(_T("\n\t Linux "));
     if(platform::macos)
         info.append(_T("\n\t MacOS "));
-    if(platform::unix)
+    if(platform::unix_a)
         info.append(_T("\n\t Unix "));

     info.append(platform::unicode ? _T("Unicode ") : _T("ANSI "));

I also uploaded the patch here ( i'm not sure if the pasted version will keep the tabs ): http://cop.tfm.ro/files/codeblocks_compile_fix.diff
Use it: get the svn tree svn checkout http://svn.berlios.de/svnroot/repos/codeblocks/trunk
and do:  patch p0 < codeblocks_compile_fix.diff


Best regards,
Mihai (Cop) Moldovanu
TFM Group Software Romania

thomas:

--- Quote from: Der Meister on March 13, 2007, 12:12:29 am ---Killerbot already commited a (temporary?) fix for this in revision 3687 but thomas just reverted it in revision 3690. I have no idea why and no idea whether Killerbot's fix really worked or could be used for the future (as it was marked temporary).

--- End quote ---
Inadvertedly... was not aware that change was actually in the repo.

During the normal update-recompile-commit cycle for the next change, compilation suddenly failed. Due to "check for externally modified files" being turned off for some reason, Code::Blocks didn't care to tell me the file had changed.
Thus I tried about 20 times to compile, and the compiler kept telling me that two variables were not defined, although the editor clearly showed they were. By coincidence, I closed the editor at some point and after reopening, I found some extra characters that I did not put there. Of course it could not compile that way!
Thus my thought was "wtf... now it gets funny... now the editor inserts random letters...???". So I removed them, and it all compiled fine again. Made a mental note to check the editor asap, and committed this "revert" with the other stuff.

As to whether renaming the variable works, yes it does, but it is not pretty and it is not right. What's annoying is that it is an entirely legal name, and what the compiler is doing there isn't good.
We're presently discussing what to do. With some luck, adding -U to CFLAGS will work (not tried yet). If this doesn't work out, we'll rename all variables (not just the two) to some other scheme.

thomas:
Good news:  CFLAGS works :)

Thanks to Biplab for testing.

Navigation

[0] Message Index

[#] Next page

Go to full version