Author Topic: How can I biuld codeblocks with codeblocks on linux (Read 42583 times)

ccsee · « **on:** May 08, 2009, 06:24:20 am »

I have downloaded both codeblocks8.0.2 source code and release version.
And i use codeblocks to open CodeBlocks-unix.cbp which is in src directory.
When tried to compile it, I got errors below. Forget the irrecognized characters,they are not english.

/home/ccsee/develop/wxGTK-2.8.10/include/wx/defs.h|42|閿欒锛?#error "No Target! You should use wx-config program for compilation flags!"|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/cursor.h|40|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€楪dkCursor鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/cursor.h|40|閿欒锛?expected 鈥?鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/app.h|55|閿欒锛?鈥榞uint鈥欐病鏈夊懡鍚嶄竴涓被鍨媩
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/app.h|65|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€楪dkVisual鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/app.h|65|閿欒锛?expected 鈥?鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/colour.h|26|閿欒锛?expected 鈥?鈥?or 鈥?..鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/colour.h|26|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€楪dkColor鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/colour.h|42|閿欒锛?鈥楪dkColormap鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/colour.h|45|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€楪dkColor鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/colour.h|45|閿欒锛?expected 鈥?鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/region.h|59|閿欒锛?expected `)' before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/region.h|61|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€楪dkRegion鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/region.h|61|閿欒锛?expected 鈥?鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/window.h|1133|閿欒锛?鈥榃XWidget鈥欐病鏈夊懡鍚嶄竴涓被鍨媩
/home/ccsee/develop/wxGTK-2.8.10/include/wx/window.h|1135|閿欒锛?鈥榃XWidget鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/window.h|1293|閿欒锛?瀛楁鈥榤_palette鈥欑被鍨嬩笉瀹屽叏|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/window.h||In member function 鈥榳xPalette wxWindowBase::GetPalette() const鈥?|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/window.h|1142|閿欒锛?杩斿洖鍊肩被鍨嬧€榮truct wxPalette鈥欎笉瀹屽叏|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/window.h|1142|閿欒锛?鈥榤_palette鈥欏湪姝や綔鐢ㄥ煙涓皻鏈０鏄巪
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?expected initializer before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欏湪姝や綔鐢ㄥ煙涓皻鏈０鏄巪
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?typedef鈥楥MPFUNC_wxArraywxArrayGdkWindows鈥欒鍒濆鍖?鏀圭敤 __typeof__)|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欏湪姝や綔鐢ㄥ煙涓皻鏈０鏄巪
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榩Item1鈥欏湪姝や綔鐢ㄥ煙涓皻鏈０鏄巪
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欏湪姝や綔鐢ㄥ煙涓皻鏈０鏄巪
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榩Item2鈥欏湪姝や綔鐢ㄥ煙涓皻鏈０鏄巪
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€榑wxArraywxArrayGdkWindows鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?expected 鈥?鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?expected `;' before 鈥榑wxArraywxArrayGdkWindows鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€榑wxArraywxArrayGdkWindows鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?expected 鈥?鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?expected `;' before 鈥榑wxArraywxArrayGdkWindows鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€榑wxArraywxArrayGdkWindows鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?expected 鈥?鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?expected `;' before 鈥榠nt鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥楥MPFUNC_wxArraywxArrayGdkWindows鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欐病鏈夊懡鍚嶄竴涓被鍨媩
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欐病鏈夊懡鍚嶄竴涓被鍨媩
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|19|閿欒锛?鈥榑wxArraywxArrayGdkWindows鈥欐病鏈夊懡鍚嶄竴涓被鍨媩
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|132|閿欒锛?鈥榃XWidget鈥欐病鏈夊懡鍚嶄竴涓被鍨媩
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|171|閿欒锛?ISO C++ 涓嶅厑璁稿０鏄庢棤绫诲瀷鐨勨€楪tkWidget鈥檤
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|171|閿欒锛?鈥楪tkWidget鈥欏０鏄庝负鈥榲irtual鈥檉ield|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|171|閿欒锛?expected 鈥?鈥?before 鈥?鈥?token|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|172|閿欒锛?鈥楪tkWidget鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|186|閿欒锛?鈥楪tkWidget鈥欐湭澹版槑|
/home/ccsee/develop/wxGTK-2.8.10/include/wx/gtk/window.h|187|閿欒锛?鈥楪tkWidget鈥欐湭澹版槑|
||More errors follow but not being shown.|
||Edit the max errors limit in compiler options...|
||=== Build finished: 50 errors, 0 warnings ===|

ollydbg · « **Reply #1 on:** May 08, 2009, 06:49:00 am »

Please use english language, so that people can understand the compiler output.

ccsee · « **Reply #2 on:** May 08, 2009, 07:48:26 am »

mainly error "No Target! You should use wx-config program for compilation flags!"

The error is caused by wxWidget.
What can I do?

MortenMacFly · « **Reply #3 on:** May 08, 2009, 08:05:10 am »

Quote from: ccsee on May 08, 2009, 07:48:26 am

What can I do?

Ask in a wxWidgets forum?

If I look into def.h (on windows) I see:

Code

/*  Make sure the environment is set correctly */
#   if defined(__WXMSW__) && defined(__X__)
#       error "Target can't be both X and Windows"
#   elif defined(__WXMSW__) && defined(__PALMOS__)
#       error "Target can't be both PalmOS and Windows"
#   elif !defined(__WXMOTIF__) && \
         !defined(__WXMSW__)   && \
         !defined(__WXPALMOS__)&& \
         !defined(__WXGTK__)   && \
         !defined(__WXPM__)    && \
         !defined(__WXOSX_CARBON__)   && \
         !defined(__WXOSX_COCOA__)   && \
         !defined(__WXOSX_IPHONE__)   && \
         !defined(__WXCOCOA__) && \
         !defined(__X__)       && \
         !defined(__WXMGL__)   && \
         !defined(__WXDFB__)   && \
         !defined(__WXX11__)   && \
          wxUSE_GUI
#       ifdef __UNIX__
#           error "No Target! You should use wx-config program for compilation flags!"
#       else /*  !Unix */
#           error "No Target! You should use supplied makefiles for compilation!"
#       endif /*  Unix/!Unix */
#   endif
#endif /*__cplusplus*/

So you see what causes the error... probably (I don't have wxGTK on Windows).

In addition: Without the compilation command (thus full compile log) we can't help you much. See my sig on how to enable full compiler logging and post again the full log.

ccsee · « **Reply #4 on:** May 11, 2009, 03:32:24 am »

Thank you for your reply!
I tried to build codeblocks in the terminal.This time, i successed.
But How can I build codeblocks with codeblocks on linux?

MortenMacFly · « **Reply #5 on:** May 11, 2009, 07:54:07 am »

Quote from: ccsee on May 11, 2009, 03:32:24 am

But How can I build codeblocks with codeblocks on linux?

Open the unix workspace file and hit compile. In addition you might want to open the (unix) plugins workspace file and hit compile, too.

Jenna · « **Reply #6 on:** May 11, 2009, 10:44:27 am »

After compiling "CodeBlocks-unix.cbp" and (if wanted) "ContribPlugins-unix.workspace", you have to run "./update" from the commandline (it's in the same directory as the main project/workspace-files), even if you want to start C::B from inside C::B, because otherwise you are missing some resource-files.

ccsee · « **Reply #7 on:** May 13, 2009, 04:11:22 am »

Successly build.I think that it works correctly after “apt-get update” .
Thank you!

oBFusCATed · « **Reply #8 on:** May 29, 2009, 06:55:10 pm »

Hello,
How can I debug the code-completion plugin inside C::B?
I've remove the stripping from the update script,
added -g to the code-completion target,
rebuild it
and executed the update script again.

But I still can't debug it?
If I debug code from the sdk(inside cbeditor.cpp) it works.

Here is one of the error messages:
No line 784 in file "/home/obfuscated/projects/codeblocks/brances/wxfnb_to_wxaui/src/plugins/codecompletion/parser/parser.cpp".

ollydbg · « **Reply #9 on:** May 30, 2009, 03:14:15 am »

Quote from: oBFusCATed on May 29, 2009, 06:55:10 pm

Hello,
How can I debug the code-completion plugin inside C::B?
I've remove the stripping from the update script,
added -g to the code-completion target,
rebuild it
and executed the update script again.

But I still can't debug it?
If I debug code from the sdk(inside cbeditor.cpp) it works.

Here is one of the error messages:
No line 784 in file "/home/obfuscated/projects/codeblocks/brances/wxfnb_to_wxaui/src/plugins/codecompletion/parser/parser.cpp".

For me, I just log out some thing to "Debug log" panel.

oBFusCATed · « **Reply #10 on:** May 30, 2009, 09:55:02 am »

I tried to log with LogError, but it crashed

ollydbg · « **Reply #11 on:** May 30, 2009, 10:00:15 am »

Quote from: oBFusCATed on May 30, 2009, 09:55:02 am

I tried to log with LogError, but it crashed

No, you should use this way I wrote in wiki page:

http://wiki.codeblocks.org/index.php?title=Code_Completion_Design#Debug_Log_output

oBFusCATed · « **Reply #12 on:** May 31, 2009, 02:07:03 pm »

DebugLog crashed too

I've taken a look at the code and I think the crash is caused by a race condition.
I could not find any thread safety protection mechanisms for the logging class.

There are ::temp_string and ::newline_string which are global.
I've replaced them with local variables, but again got a crash, this time it was AppendText.
Do you know if this method can be called from two threads simultaneously?
I've added a wxMutex, but still got the crash

ollydbg · « **Reply #13 on:** May 31, 2009, 02:25:17 pm »

In Windows, I didn't encounter any crash. I'm not sure this DebugLog can be called from different thread, but it seems it can.

You need a more sophisticated dev to tell you the details.

oBFusCATed · « **Reply #14 on:** May 31, 2009, 02:44:15 pm »

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

ollydbg · « **Reply #15 on:** May 31, 2009, 03:09:27 pm »

Quote from: oBFusCATed on May 31, 2009, 02:44:15 pm

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 · « **Reply #16 on:** May 31, 2009, 11:06:31 pm »

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

MortenMacFly · « **Reply #17 on:** June 02, 2009, 08:20:19 am »

Quote from: oBFusCATed on May 31, 2009, 02:44:15 pm

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 · « **Reply #18 on:** June 30, 2009, 02:59:56 am »

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:

Quote

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 · « **Reply #19 on:** June 30, 2009, 10:10:16 am »

It looks like you have not removed the pch correctly

Jenna · « **Reply #20 on:** June 30, 2009, 07:13:58 pm »

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 · « **Reply #21 on:** July 01, 2009, 03:40:41 am »

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 · « **Reply #22 on:** July 01, 2009, 06:50:25 am »

Quote from: jens on June 30, 2009, 07:13:58 pm

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 · « **Reply #23 on:** July 01, 2009, 03:25:20 pm »

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 · « **Reply #24 on:** July 01, 2009, 03:58:06 pm »

Quote from: jens on July 01, 2009, 03:25:20 pm

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.

Quote from: jens on July 01, 2009, 03:25:20 pm

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 · « **Reply #25 on:** July 01, 2009, 07:21:33 pm »

Quote from: MortenMacFly on July 01, 2009, 03:58:06 pm

Quote from: jens on July 01, 2009, 03:25:20 pm
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.

Quote from: MortenMacFly on July 01, 2009, 03:58:06 pm

Quote from: jens on July 01, 2009, 03:25:20 pm
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 · « **Reply #26 on:** July 01, 2009, 07:41:04 pm »

Quote from: jens on June 30, 2009, 07:13:58 pm

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?

Quote

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 · « **Reply #27 on:** July 01, 2009, 07:50:24 pm »

Quote from: oBFusCATed on July 01, 2009, 07:41:04 pm

Quote from: jens on June 30, 2009, 07:13:58 pm
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 · « **Reply #28 on:** July 03, 2009, 12:27:15 am »

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 · « **Reply #29 on:** July 12, 2009, 06:11:43 pm »

Quote from: jens on July 03, 2009, 12:27:15 am

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.

stahta01 · « **Reply #30 on:** July 12, 2009, 08:19:56 pm »

Quote from: jens on July 12, 2009, 06:11:43 pm

Quote from: jens on July 03, 2009, 12:27:15 am
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.

If you build Code::Blocks under windows sdk.h is already precompiled during the main exe build.
target "src"

Edit: Just looked at C::B Unix project and it sdk.h is not precompiled for it.

Tim S

oBFusCATed · « **Reply #31 on:** August 26, 2009, 08:06:15 pm »

Why do I need to apply this patch, in order to run cb from cb (on linux)

Code

Index: src/main.cpp
===================================================================
--- src/main.cpp        (revision 5712)
+++ src/main.cpp        (working copy)
@@ -1015,11 +1015,13 @@
     m_PluginIDsMap.clear();
 
     PluginManager* m_PluginManager = Manager::Get()->GetPluginManager();
+    int count = 0;
+    wxString path;
 
-    // user paths first
-    wxString path = ConfigManager::GetPluginsFolder(false);
-    Manager::Get()->GetLogManager()->Log(_("Scanning for plugins in ") + path);
-    int count = m_PluginManager->ScanForPlugins(path);
+//    // user paths first
+//    path = ConfigManager::GetPluginsFolder(false);
+//    Manager::Get()->GetLogManager()->Log(_("Scanning for plugins in ") + path);
+//    count += m_PluginManager->ScanForPlugins(path);
 
     // global paths
     path = ConfigManager::GetPluginsFolder(true);

Without the patch C::B starts but no plugins are loaded...

Jenna · « **Reply #32 on:** August 26, 2009, 09:44:46 pm »

Quote from: oBFusCATed on August 26, 2009, 08:06:15 pm

Why do I need to apply this patch, in order to run cb from cb (on linux)

Don't know, works fine here.

Can you post the output from the "Code:Blocks" tab in the "Logs & others" window ?

oBFusCATed · « **Reply #33 on:** August 26, 2009, 11:23:05 pm »

Here it is

Code


Scanning for lexers in /home/obfuscated/projects/codeblocks/brances/codecompletion_refactoring/src/devel/share/codeblocks/lexers/...
Found 41 lexers
Loading lexer_haskell
Loading lexer_f77
Loading lexer_properties
Loading lexer_ada
Loading lexer_latex
Loading lexer_OgreCompositor
Loading lexer_rc
Loading lexer_xml
Loading lexer_OgreMaterial
Loading lexer_glsl
Loading lexer_gm
Loading lexer_vbscript
Loading lexer_postscript
Loading lexer_angelscript
Loading lexer_vhdl
Loading lexer_html
Loading lexer_squirrel
Loading lexer_d
Loading lexer_lua
Loading lexer_perl
Loading lexer_smalltalk
Loading lexer_prg
Loading lexer_matlab
Loading lexer_fortran
Loading lexer_batch
Loading lexer_ruby
Loading lexer_css
Loading lexer_lisp
Loading lexer_caml
Loading lexer_bash
Loading lexer_diff
Loading lexer_hitasm
Loading lexer_cg
Loading lexer_make
Loading lexer_cpp
Loading lexer_sql
Loading lexer_masm
Loading lexer_nsis
Loading lexer_pascal
Loading lexer_verilog
Loading lexer_python
Configured 0 tools
Scanning for plugins in /home/obfuscated/.codeblocks/share/codeblocks/plugins
Plugin resource not found: cbMakefileGen.zip
Loaded 1 plugins
Scanning for plugins in /plugins
Loading:

Jenna · « **Reply #34 on:** August 27, 2009, 12:00:46 am »

It seems you have an incompatible vewrsion of the cbMakeFileGen-plugin in C::B's user-plugin folder.

Try to rename (or empty) the /home/obfuscated/.codeblocks/share/codeblocks/plugins-folder.
If you remove or empty the folder you should also remove the cbMakeFileGen.zip-file, if you only rename the folder, to test it, you can leave it where it is.

If the folder is removed or renamed, C::B will create a new one at next start.

You have to stop C::B before you do this of course.

I think C::B should not stop loading the other plugins, but show a message about not loaded plugins.

I will have a look into it.

You might want to file a bug report, so that this issue does not get lost.

I try not to forget it anyway ...

Jenna · « **Reply #35 on:** August 29, 2009, 11:59:47 pm »

The problem seems to be a little bit more difficult as it looks on first sight.

I have a test-plugin in my user-plugin-folder.

C::B loads it, but cannot load the appropriate zip-file, because immediately after loading the .so-file, all global values in (at least) configmanager are lost.

The plugin is linked a gainst the libcodeblocks.so in /usr/lib (belonging to my regular C::B installation aka nightly).

It seems that loading the plugin also reloads libcodeblocks, but (most likely) the wrong one and therefore loses all the formerly initialised global variables.

Therefore it tries to search the zip-file and all other plugins in wrong folders.
Most likely many other init-values get lost also (I did not check this).

The only way to avoid this, seems to be to remove either the "wrong" plugin, or the libcodeblocks.so in /usr/lib.
The first one makes the plugin unusable for the regular C::B executable, the second makes the whole regular C::B unusable.

I don't see an easy solution at the moment.

News:

Author Topic: How can I biuld codeblocks with codeblocks on linux (Read 42583 times)

bruin

bruin