Code::Blocks compiles in 64 bit Linux!!

[Promit]

Just got it going today! Had to make one minor change, but it's really up and running. So I finally have a decent IDE for my 64 bit Gentoo system.

Getting it to work is actually fairly simple. There's a line in Makefile.unix like so:
PROJECT_CFLAGS= -Wall -g `wx-config --cflags`
To get it to compile properly on the Athlon64, it must read:
PROJECT_CFLAGS= -fPIC Wall -g `wx-config --cflags`

I'm not entirely sure why -fPIC is required on the A64 and not on regular x86; some kind of architectural change I guess. Quick research suggests that -fPIC is safe to add even in 32 bit compiles, where at worst it will have no effect.

I've only done some very cursory testing, but everything seems fine with just one exception. Loading the code completion plugin causes the IDE to crash upon closing. I did notice some int/pointer hackery warnings during the compile, but I fixed the code to work on 64 bit (as far as I could tell) and it has not prevented the crash. I'm still poking around the codecompletion source to see if anything obvious shows up.

Mandrav: You were using wxCommandEvent::SetInt in several places to pass a Parser*. This is naturally no longer allowed, since int remains 4 bytes while Parser* is 8. I modified the code to always use wxCommandEvent::SetExtraLong instead of SetInt, but that didn't actually prevent the crash, even after modifying ALL of the SetInt calls rather than just the ones that used SetInt to transfer a pointer. I'm looking around the source, but if you have any insight as to where the problem might be, that'd be greatly appreciated.

[Promit]

In retrospect this post was probably better off in development. Ah well.

[Promit]

Oh, and I should've probably registered before posting too  :lol:

[Promit]

Ok, well it looks like I've fixed the shutdown crash finally. A size_t was being passed as an int to a printf. But when I go to Settings->Configure Plugins->Code Completion, the IDE just freezes. Still investigating why; this doesn't appear to affect any other plugin.

[EDIT] Actually invoking code completion also freezes.

[mandrav]

Just got it going today! Had to make one minor change, but it's really up and running. So I finally have a decent IDE for my 64 bit Gentoo system.

That's amazing!

Mandrav: You were using wxCommandEvent::SetInt in several places to pass a Parser*. This is naturally no longer allowed, since int remains 4 bytes while Parser* is 8

You 're right. It was a quick-hack to pass around the Parser* while developing and it got left in there. What's worse, I forgot about it...
Thanks for reminding me

Actually invoking code completion also freezes

I 've noticed it too, lately. The code completion plugin was always a little shakey under linux but never freezed the app (it might have crashed it sometimes, but no freezes). There have been some changes in the parser threading lately. I 'm not sure that's what's caused it, but I 'll investigate some more.

I hope you 'll send us a patch with the changes you made

Yiannis.

[Promit]

I played with the code some more, but I haven't managed to get it to not freeze when the code completion is invoked.

I suppose this would be a good time to test the gdb plugin's functionality, eh?  :lol: I had to make one relatively minor change in the Code::Blocks source to get it to not crash at close when the plugin was loaded, but I'm pretty stumped with the freezing. I am not really too familiar with the internals, I just ran some quick searches looking for obvious places that would break under 64 bit.

But yeah, afaict things basically work. It looks like the -fPIC option to GCC is perfectly safe on x86, so you can add it permanently to the project compile options if you want. I'll submit the change I made to the core source as soon as I get back in Linux and remember what that change was  

[mandrav]

It looks like the -fPIC option to GCC is perfectly safe on x86, so you can add it permanently to the project compile options if you want.

OK then

Yiannis.

[Neutron]

Note that -fPIC should really only be used for compiling shared libraries and not executables. This option should probably be set by CodeBlocks when compiling shared library projects too. More information here: http://www.google.com/url?sa=U&start=2&q=http://gcc.fyxm.net/summit/2003/Porting%2520to%252064%2520bit.pdf&e=9707

I have compiled codeblocks-1.0-finalbeta on my AMD64 gentoo machine and can reproduce the code completion freeze. Disabling the code completion plugin, i was able to compile a hello world progrm using Code::Blocks. However, when i changed a compile option (enabled compiling debug information under project options), Code::Blocks seg faults when i click the compile button.

Here is beginning of the backtrace:
#0  0x00002aaaabdb4076 in regcomp () from /lib/libc.so.6
#1  0x00002aaaaf181704 in headers1 ()
   from /home/joaander/test-codeblocks/codeblocks-1.0-finalbeta/src/output/share/CodeBlocks/plugins/libcompilergcc.so
#2  0x00002aaaaf181945 in headers ()
   from /home/joaander/test-codeblocks/codeblocks-1.0-finalbeta/src/output/share/CodeBlocks/plugins/libcompilergcc.so
#3  0x00002aaaaf180a00 in depsScanForHeaders ()
   from /home/joaander/test-codeblocks/codeblocks-1.0-finalbeta/src/output/share/CodeBlocks/plugins/libcompilergcc.so
#4  0x00002aaaaf18a285 in DirectCommands::IsObjectOutdated ()
   from /home/joaander/test-codeblocks/codeblocks-1.0-finalbeta/src/output/share/CodeBlocks/plugins/libcompilergcc.so
#5  0x00002aaaaf18845a in DirectCommands::GetTargetCompileCommands ()
   from /home/joaander/test-codeblocks/codeblocks-1.0-finalbeta/src/output/share/CodeBlocks/plugins/libcompilergcc.so
#6  0x00002aaaaf18801e in DirectCommands::GetCompileCommands ()
   from /home/joaander/test-codeblocks/codeblocks-1.0-finalbeta/src/output/share/CodeBlocks/plugins/libcompilergcc.so
#7  0x00002aaaaf16f1c2 in CompilerGCC::Compile ()
   from /home/joaander/test-codeblocks/codeblocks-1.0-finalbeta/src/output/share/CodeBlocks/plugins/libcompilergcc.so
#8  0x00002aaaaf170479 in CompilerGCC::OnCompile ()

[mandrav]

I noticed it just this weekend. Here's what happens, in case anyone knows how to fix it.
The depslib contains a file regexp.c which defines regcomp(). When it crashes, the backtrace shows the crash in regcomp() inside libc6 (!). Somehow another regcomp is used instead of the included one.
A quick fix is to rename regcomp() to, say, myregcomp() in regexp.c, regexp.h and headers.c (under plugins/compilergcc/depslib/src). This stops the crash, but I don't understand why it's using a "foreign" regcomp() in the first place...
Unfortunately, with this fix, it stops working correctly with the dependencies (this is what it's all about).
I didn't have the chance to look into it more, but I plan to.

Yiannis.

[Anonymous]

>> but I don't understand why it's using a "foreign" regcomp() in the first place...

well, it's part of libc, then "your regcomp" is less preferred than the one in libc.
usually you __don't __ use the same function name that is available in libc.

just my 2 cents

[mandrav]

>> but I don't understand why it's using a "foreign" regcomp() in the first place...

well, it's part of libc, then "your regcomp" is less preferred than the one in libc.
usually you __don't __ use the same function name that is available in libc.

just my 2 cents

You 're right, but I hadn't noticed it before. This code (the whole depslib) was contributed by another user.
Anyway, if I rename the regcomp() function to, say, my_regcomp() it stops freezing but it's not working either  :?
Still haven't had the time to investigate...

Yiannis.

[Neutron]

Working on a different linux machine (32-bit on this one) and i get the same regcomp crashes.

Following the suggestions here to change regcomp to my_regcomp and tried it and it didn't work. I even removed the code from regexp.h and regexp.c and forced depslib to use the libc functions without luck.

Apparently, the regcomp and friends called in depslib headers.c are not at all compaticble with the libc regcomp and friends.  So, in regexp.h, i changed all the functions to start with my, since the all conflict with libc ones (that is, I now have my_regcomp, my_regexec, my_regerror, and my_redone). I then updated all associated function calls in regexp.c and headers.c to use the my_* functions (only a few to update, its not bad).

And now it all works .  I would guess this fixes the problem under 64-bit linux too. I'll post here if i find otherwise.

[rickg22]

:shock: PLEASE SUBMIT A PATCH!!!

Thank you

[Anonymous]

:shock: PLEASE SUBMIT A PATCH!!!

Thank you

No problem: https://sourceforge.net/tracker/index.php?func=detail&aid=1224472&group_id=126998&atid=707418