Code::Blocks with C/C++ Compiler

[Loonie]

Now I'm wondering if there's something weird going on with my system. Unfortunately I didn't keep the last working version. Do you still have the PND for v1.02.03 handy? I should test to see if it still works, before you do too much chasing after something that might not be on your side.

 

[ptitSeb]

It should be available on the repo, with the Archive button (I haven't archived all PND on my HDD).


Have you tried the "Command Line C/C++", the "sudo ldconfig -f init/ld.so.cfg" is in the same Terminal as the ...well..., Terminal of the command line (I see I'm not that clear with this sentence)...

 

[Loonie]

...How the hell have I not noticed the big "Archived" button before?? I'll try it out tonight.


I have noticed something weird going on with .sh scripts on my system. I can't launch them from the file manager, and if I try to run one from the terminal, it simply tells me "command not found", even though a "dir" command reveals the script is right there.

 

[ptitSeb]

Wow, the "sh" thing is a little weird (don't forget to use ./ in front of the script). Your may have to flash your unit.

 

[Loonie]

Oops. There goes my Linux noobishness again. A quick test script does indeed work with the ./ prefix). Anyhow, I shall test the older version when I get home to see if that still works.

 

[ptitSeb]

Ah yes, Linux is sometimes strange, where does this need to precise "./" (meaning "here"), when it's obvious it's here...


Anyway, yes, a downgrade is a good test.


Also, a good test before is to launch the "C/C++ Command Line Interface" (with the last PND), and see what is on the Terminal that opens. It should write, near the end, "Testing for the need of a ldconfig", and I assume it will be needed, so it will try a "sudo ldconfig -f init/ld.so.cfg"


If something is strange also, you may remove the "init" folder of the appdata/codeblocks, so it will recreate important files (the ones that directs the standard <includes> to /mnt/utmp/codeblocks/usr/include and make the ld finds it's libraries in mnt/utmp/codeblocks/usr/lib).

 

[Loonie]

I tried deleting the codeblocks folder from the appdata altogether, but the latest version still produces that error.


The command line interface issues the following message when testing the need for ldconfig:

bash: init/cb_ldd_output: Operation not permitted

 

[Loonie]

I've reverted to version 1.0.2.03. The console appears the first time it is run, and compilation is working.

 

[ptitSeb]

Ah, thanks Loonie. I have all the informations I need. I will be able to bring a working update (a bigger one, as I added more libs, like alsa-libs 1.0.25 and lua 5.2 for example).

 

[ptitSeb]

Ok, I found it. I have left the "init" and "home" folder in PND, where they must be created... That's why you had "permission denied". New PND coming soon.

 

[ptitSeb]

New update on the repo :


Update v1.03.06:

• Fixed a regression that prevented ldconfig to be launched properly
  
• Remove bosst library, I think there where not well installed
  
• Added Lua 5.2 and Alsa-lib 1.0.25
  

Removing Boost library has reduced the size of the PND (from 208Mo -> 162Mo more or less). If Boost was a "must have", just say it and I re-add it.

 

[Loonie]

Alright! Looks like we're back in action. Launched the latest build after doing a reboot and up popped the console, asking for the magic word, and compilation is once again working.


Actually, the former working version would throw up a couple of errors in the console before launching codeblocks, though it still worked anyway, so I didn't think anything of it. This latest version doesn't seem to throw out any errors at all.


Once again, top job, Seb.

 

[ptitSeb]

Thank you Loonie.


I think I will wait for the new Code::Block stable release (seems it will be 12.11) to update the PND now.

 

[ptitSeb]

I Continued working on the Code::Block PND, waiting for the next stable release of Code::Blocks.


I wanted to upgrade the compiler to ... a newer one.


And, I only realize now: what a task !


So I get the sources of the latest (stable) GCC : 4.7.2. tar, ./configure... oh, missing dependencies... GMP, MPFR and MPC... Ok, not a big deal.


a few hours later (all takes times on the pandora)... ./configure again


and then make


..


failed


ok, messing with with options of ./configure


make


failed


..


many attemps latter, I hit a wall: ARM blabla trucate blabla... After a little google, well, ARM has some limitations, and cannot do certain jump (I'm not fluent in ARM assembler) longer than 32Mo (limit is 24bit, like 68000 iirc)... Need to upgrade the linker.


Hum... Liker is part of Binutils package.


So, let's jump from 1.18 to the latest.. 1.23.1


Ok, get


tar


./configure


make


works !


make install


So far so good.


Back to gcc 4.7.2... just to realize that the linker doesn't work ! Some kind of "assertion failed"... and it failed.


Ok, I tried with Binutils 1.23... Same. Try with 1.19, works, but same error on GCC 4.7.2.


Binutils 1.22...


Well, there are many "assertion failed ... 11647 and 11667", but it (looks like it) works.


Back to GCC 4.7.2... to failed again, and again, and again.


So I decided to be less ambitious, and I took GCC 4.6.3.


I used --disable-multilib and only compiled c and c++, but this time it works !


So now, the CodeBlocks PND is running with GCC 4.6.3 and Binutils 1.22


There are many "assertion failed" when linking, but programs seem to be ok. I am not sure if it interferes or not with ./configure, so may be I will downgrade to 1.21 or 1.20 (or 1.19, I know this one works without failed assertions).


As a quick test, I recompile DeadBeef, with all optimization enabled ... but the "top" monitoring doesn't look better (it's not worse either). I still have 10% cpu for mp3 and 35% cpu for psf.

 

[ptitSeb]

Ok, New update on the Repo


Update v1.04.07 contains:

• Update Code::Blocks to 12.11rc2 (rev 8619)
  
• Update GCC to 4.6.3 (from 4.3.3)
  
• Update Binutils to 2.22 (from 2.18)
  
• Update Git to 1.8 (from 1.7.0.2)
  
• Add/Update numerous libs & tools (GNU TexInfo 4.13a, Bison 2.6, Zip 3.0, Unzip 6.0, Doygen 1.8.2, etc.)
  

You should note:

• wxWidget path has changed from .../codeblocks/wx/2.8 to .../codeblocks/wx (sorry for the inconvenience, but should be pretty transparent).
  
• ld (the linker) produce somes armless messages (assertion failled). All seems to works perfectly anyway.
  

Because Code::Blocks is a RC and the GNU has been update and the messages of ld, I tagged the PND as "beta". It seems fully functionnal anyway (builded DeaDBeaf build 05 and Cataclysm Roguelike with it).


I also tested Code::Block, and found no particular problems (ok, a wxWidget test project that I copied from the PC act strangely, but a new project just work, so I guess I messed up something).


Please report if something is wrong.

 

[Loonie]

Hi Seb,


Took it for a spin. The initial console throws out an error of some description while doing its thing (I believe you mentioned that possibility), but everything seems to be working regardless. In fact, I think my SDL test case is running a tiny bit faster. Good job, as usual.


Man, that menu bar is getting pretty cramped!

 

[ptitSeb]

Ah yes, with all the plugins (I compiled the contrib plugins this time).. well, the "Help" menu is out of the screen. Don't think there is a way to reduce font size for menu...

 

[Loonie]

It also makes for a positively gargantuan right-click menu as well. Luckily I just realized on the metro to work that since I'm not using most of those plugins I could just disable them. That made the right-click menu and menu bar more modestly sized.


I never really imagined Code::Blocks would be so usable on Pandora. I had only been using the official releases (10.something) before, but this version 12 RC seems pretty decent. Perhaps I'll try it on the laptop.

 

[ptitSeb]

Yeah, exactly what I was thinking: I have to install that new version on my main PC, looks realy good.


Anyway, I think it's better to have too much plugins and have the ability to deactivate them, rather than missing the one plugin you use on a regular basis..


I haven't found a way to reduce the size of the font (but I haven't look much)

 

[Loonie]

Oh, I'm not at all implying that the plug-ins should be removed, the more the merrier. Since they can be disabled, they pose no problem.