How can I biuld codeblocks with codeblocks on linux

[ollydbg]

It might be something different in wxGTK, than wxMSW (or its proper name). So you are lucky.

Do someone now if I can disable the precompiled header?
I'm 100% sure that it is the cause of the broken debugging and strange error messages that I receive:

Code

In file included from /home/obfuscated/projects/codeblocks/brances/wxfnb_to_wxaui/src/include/sdk_precomp.h:10:
include/editorbase.h: In member function ‘wxArrayString Parser::FindFileInIncludeDirs(const wxString&, bool)’:
include/editorbase.h:1092: error: ‘_1’ was not declared in this scope

stahta01 had done some non-pch build, you can ask him.

[oBFusCATed]

No need,
I've hacked it and now I have non-pch build with working the debugging of plugins

[MortenMacFly]

Do someone now if I can disable the precompiled header?

Undefine USE_PCH and WX_PRECOMP, define NOPCH and do not use -Winvalid-pch.

[bruin]

Hello,

I can't debug Codeblocks from inside Codeblocks either.

I've built Codeblocks from inside Codeblocks and removed the strip commands from update. I've also followed the instructions to build without precompiled headers.

The program starts normally, but I'm trying to set breakpoints, and I always have this output:

Building to ensure sources are up-to-date
Build succeeded
Selecting target:
src
Adding source dir: /home/codeblocks/trunk/src/
Adding source dir: /home/codeblocks/trunk/src/
Changing directory to: devel
Adding file: devel/codeblocks
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.8-debian
No source file named /home/codeblocks/trunk/src/plugins/debuggergdb/debuggertree.cpp.
Breakpoint 1 ("/home/codeblocks/trunk/src/plugins/debuggergdb/debuggertree.cpp:138) pending.

The breakpoint is always pending. gdb doesn't seems to be finding the source files. This happens with command-line gdb as well. Any suggestions would be appreciated!

Cheers

[oBFusCATed]

It looks like you have not removed the pch correctly

[Jenna]

It worked (and works) without turning precompiled headers off with gcc < 4.3.

Since 4.3 there seem to be problems with line numbers in some cases.
I found just one post about this issue, but without a solution: http://gcc.gnu.org/ml/gcc-help/2008-10/msg00209.html.

For me it only works (with gcc >= 4.3), if I totally turn off precompiled-headers. NOPCH or not using CB_PRECOMP or WX_PRECOMP is not enough.

The only way to totally turn off precompiled headers is in the "Advanced" section of the compiler settings, but that works globally for all projects and is not what I expect.
I use a copy of my gcc for that purpose.

In the project's properties, I am only able to chose the place where the pch is created, but not if it is created or not.
Or do I miss something?

I think a simple checkbox ("Use precompiled headers"), that is checked by default would make sense (in the properties).

What does the other devs think about it ?

[bruin]

Jens nailed the problem. It works for me if I turn off precompiled headers in settings/compiler/other settings/advanced.

Also, you have to rebuild the whole project. If you rebuild only the target you want to debug, it will still have bad line numbers in the debug info.

[MortenMacFly]

What does the other devs think about it ?

In fact this was (and is) a bit confusing for me, too. Hence I can disable PCH if I do the steps as I described somewhere else in this forum.
But a checkbox might really be more convenient.

In addition I have modified the code in compilerMINGWgenerator.cpp like this:

Code

Index: src/plugins/compilergcc/compilerMINGWgenerator.cpp
===================================================================
--- src/plugins/compilergcc/compilerMINGWgenerator.cpp	(revision 5680)
+++ src/plugins/compilergcc/compilerMINGWgenerator.cpp	(working copy)
@@ -35,8 +35,9 @@
 {
     wxString result = CompilerCommandGenerator::SetupIncludeDirs(compiler, target);
     m_VerStr = compiler->GetVersionString();
-    wxString pch_prepend;
+    wxString pch_prepend = wxEmptyString;
     bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+    bool HasPCH = false; // We don't know yet if there are any header files to be compiled...
 
     // for PCH to work, the very first include dir *must* be the object output dir
     // *only* if PCH is generated in the object output dir
@@ -64,6 +65,7 @@
                     else
                         pch_prepend << _T("-iquote") << dir << _T(' ');
                 }
+                HasPCH = true; // there is at least one header file to be compiled
             }
         }
         // for gcc-4.0+, use the following:
@@ -78,9 +80,11 @@
             pch_prepend << compiler->GetSwitches().includeDirs << includedDirs[i] << _T(' ');
         }
         pch_prepend << _T("-I. ");
-        result.Prepend(pch_prepend);
     }
 
     // add in array
+    if (HasPCH)
+        result.Prepend(pch_prepend);
+
     return result;
 }

(Not exactly related to that topic but turns off the annoying warnings if there are no PCH files.)

[Jenna]

It's much simpler as I thought:

just right-click sdk_precomp.h in the project tree, click properties, chose tab Build and uncheck Compile file.
And I think you should manually remove sdk_precom.h.gch and rebuild the whole project.

That's it.

[MortenMacFly]

just right-click sdk_precomp.h in the project tree, click properties, chose tab Build and uncheck Compile file.

This is exactly what happens if you setup the specific #defines accordingly. -> Inspect the header file, it's basically "empty" even if you compile it by then.

And I think you should manually remove sdk_precom.h.gch and rebuild the whole project.

Probably that was the real problem here...?!

IMHO GCC always uses the GCH file if present (and can be found due to include folders). But I might be wrong...

[Jenna]

And I think you should manually remove sdk_precom.h.gch and rebuild the whole project.

Probably that was the real problem here...?!

IMHO GCC always uses the GCH file if present (and can be found due to include folders). But I might be wrong...

I know and I deleted it of course.

just right-click sdk_precomp.h in the project tree, click properties, chose tab Build and uncheck Compile file.

This is exactly what happens if you setup the specific #defines accordingly. -> Inspect the header file, it's basically "empty" even if you compile it by then.

I did not manage to get a gch-file with less than 3.5 MByte (the normal has about 120 MByte).

Only tried on debian 64-bit, so I do not know if something works different on windows or on 32-bit.

Nevertheless it would be fine to be able to debug with precompiled headers on, and as posted before it works with gcc < 4.3 .

[oBFusCATed]

I found just one post about this issue, but without a solution: http://gcc.gnu.org/ml/gcc-help/2008-10/msg00209.html.

I've not seen anywhere the guy stating that he is using precompiled headers.
Jen have you reported that issue to the gcc guys?

I think a simple checkbox ("Use precompiled headers"), that is checked by default would make sense (in the properties).

What does the other devs think about it ?

I support this change.
The current situation is quite confusing: you have 3 options, but none of them stops the precompiled header of being used and you have to read in the forum how to do that

[Jenna]

I found just one post about this issue, but without a solution: http://gcc.gnu.org/ml/gcc-help/2008-10/msg00209.html.

I've not seen anywhere the guy stating that he is using precompiled headers.
Jen have you reported that issue to the gcc guys?

I didn't see it either, but the problem seems to be similar, the format the linenumbers are saved int (some) files (in his case shared libs) seems to have changed from gcc 4.2 to gcc 4.3 so that gdb cannot read them in some cases.

No, I did not report.

If I mention to create a test-case a little bit simpler than C::B I probably will.

[Jenna]

Update:
all issues can be fixed, if two precompiled headers are used (as on windows).

That means adding the compile-flag to sdk.h and all problems seem to be gone.

Without that and sdk_precom.h.gch as pch, the compiler seems to be unable to examine correctly the file information.
Just force an error in a file of debugger-plugin (for example debugtree.cpp) and gcc always says the error is in the last include-file, but uses an incorrect large linenumber.

If you check the libdebugger.so-file with nm -l (to show line-numbers) you see the incorrect association between functions, files and linenumbers (that's how I found the possible solution).

Instead of precompiling sdk.h we can also include sdk_precomp.h, but that might lead to issues on windows.
What makes me wonder is, why it makes a difference whether we include sdk_precomp.h directly or indirectly via sdk.h .

So (pre)compile sdk.h seems to be the most simple solution and should (hopefully) not have any sideeffects.

Any comments or objections from users and devs that have more experience with precompiled headers are (as always) welcome.

[Jenna]

So (pre)compile sdk.h seems to be the most simple solution and should (hopefully) not have any sideeffects.

Any comments or objections from users and devs that have more experience with precompiled headers are (as always) welcome.

Again:

are there any objections (especially by other dev) against using two precompiled headers ?
Or other solutions to make C::B debuggable with gcc >= 4.3 .

If not, I would like to commit a patch.