Code::Blocks with C/C++ Compiler

[ptitSeb]

Are you using SDL2 or SDL 1.2 ?

For SDL2, the packaging can be tricky yes. Take a looks at the already ported PND for hints (RickyD from me or zSilencer from Canceco).

If it's SDL1.2, that's strange, because it usualy let it put in PND quite nicely.

To Package, make sure all the needed lib goes to the lib folder of your PND, and LD_LIBRARY_PATH will be setted automaticaly at the mount of your PND. B sure to put libSDL from codeblocks if you are using GLES, but be sure to not put libEGL, libGLES_CM or libGLESv2 from codeblocks.

PS: unseting LD_LIBRARY_PATH is not enough to test when codeblocks is mounted (beleive, I'v tried that before ). You need to "sudo ldconfig" to be sure libs are not accessibles.. And when test is done, do "sudo ldconfig -f /mnt/utmp/codeblocks/init/ld.so.cfg" to make libs accessible again to the system.

 

[elvissteinjr]

I wasn't even at packing into a PND yet, just running the binary directly.
Should've mentioned SDL2 and OpenGLES1, sorry about.

Copying in the libs from zSilencer (a few were bigger for some reason) and deleting the EGL and GLES libs did the trick. Should've been more careful with that.


Thanks for your help there. Keep up the good work!

 

[ptitSeb]

Libs are different because it's a new build, based on 2.0.1 (codeblocks only has 2.0.0) patched to make it compatible with latest Sgx drivers.

 

[ingoreis]

@ Ptitseb,can you maybe sometime in the Future release a Complete Pandora SD Card OS with all the building related Libs in?

Like a real complete OS like Slackware?

With alle the Libs from Codeblocks in?

Only a wish for the Future and only a suggestion

 

[ptitSeb]

@Ingoreis: ok, maybe on day I'll try that.But first I need an empty (not too small) SDCard, and some time (I prefer invest my time elswere for now)

 

[ingoreis]

I can Donate you an extra SD Card when you want

Or maybe send one empty from mine.

16GB or 32GB? ^_^

 

[ptitSeb]

I can Donate you an extra SD Card when you want

Or maybe send one empty from mine.

16GB or 32GB? ^_^

Current codeblocks uncompressed is a bit more 6Go. I guess if I add wxPython and MonoRT I won't go bigger than 8Go. So 16Go Card is more than enough (but I'm afraid a 8Go will be a little short)...

 

[ingoreis]

When you give me your Adress via PM then i will try to send you my fastest and best 16GB Card ^_^

I never sended anything to France before ^_^

 

[ptitSeb]

Hu, Ok. I'm not home this week (for work). we'll discuss that by PM once I'm back

 

[ingoreis]

Oki Doki,i waited for Years that anyone make a complete Pandora OS with all Building Libs realy included

I asked so often other People and noone maked that.

And with this SD Devkit can anyone of us Port Things much more easy then

Thats because i love Slackware,its very complete too

(but the Libs are not 100% Combatible for porting Things for Zaxxon there)

 

[mcobit]

Well, why not copy the /usr/include folder from the x86 toolchain into a sdinstallation of superzaxxon?


Should do the trick...

 

[elvissteinjr]

Aaand I'm back with more question for the experts. Not directly related to Code::Blocks, but with the included SDL2 build so I guess that counts.

I'm having some small issues with tearing using OpenGLES 1. Using SDL_GL_SetSwapInterval(1) did the trick for PC, but not quite on the Pandora.
What's the cleanest way to get some kind of vsync here?

 

[ptitSeb]

For tearing, you first have to switch to "flip mode" instead of default "blit mode" for pageflippng. For this, use the powervr.ini trick (grab the file from on my latest PND for example). The file should be in the current folder.

If you still have tearing, you can do some VSync yourself, grab EGLPort.cpp from Pickle, and you'll see inside how to make vsync on pandora, because SwapInterval has no effect o the Pandora...

 

[ingoreis]

Well, why not copy the /usr/include folder from the x86 toolchain into a sdinstallation of superzaxxon?


Should do the trick...

But only copying is not realy installing.

Maybe there are then some missing Files from other Folders.

Maybe important Configfiles or near Things.

I think its working but not perfect then as its compiled and installed onto the Pandora itself  ^_^

 

[sepulep]

the version of gnutls currently in codeblocks seems to be broken (e.g. doesn't work with youtube https streams - had to compile 3.2.12 ). Don't know what the problem exactly is, but it seems

there people have been finding problems with the 3.2.2 version (the one now in codeblocks)

 

[ptitSeb]

the version of gnutls currently in codeblocks seems to be broken (e.g. doesn't work with youtube https streams - had to compile 3.2.12 ). Don't know what the problem exactly is, but it seems

there people have been finding problems with the 3.2.2 version (the one now in codeblocks)

Ok, I'll make sure to update that lib before releasing next build !

 

[PowerGod]

I just want to share something I just tried, and it's very useful:

- Start Code::Blocks command line on the Pandora

- use the command "screen" and press enter

now you can do what you need to do with the compiling environment, but you can also access and interact with it from another machine even if something is already running !!

You can do this on another machine, after starting an ssh connection:

screen -D -RYou can use the same command to get back the console in the Pandora itself, without interrupting anything that's running.("screen" is a complex command, and this instruction works only if you are using a single session)

When you are finished with Code::Blocks, just do an "exit" as always.

I was using X11 forwarding before to use Code::Blocks from the PC, but there was the disadvantage that the x11 session was running on the pc itself, so I wasn't able to "get back" the console from the Pandora, in order to turn off the pc without stopping anything...

But with "screen" I found no problems for now

 

[PowerGod]

Spoiler

What can be the problem ? Some not initialized variables ?





Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /mnt/utmp/codeblocks/usr/bin/cc
Build flags: -Ofast;-pipe;-mcpu=cortex-a8;-mfpu=neon;-ftree-vectorize;-mfloat-abi=softfp;-march=armv7-a;-fsingle-precision-constant;-mno-unaligned-access
Id flags:

The output was:
1
/mnt/utmp/codeblocks/usr/libexec/gcc/armv7l-unknown-linux-gnueabi/4.8.2/cc1: error while loading shared libraries: libcloog-isl.so.4: cannot open shared object file: No such file or directory
The library exist "/mnt/utmp/codeblocks/usr/lib/libcloog-isl.so.4"
I also tried to make a symlink in the compiling root directory but nothing changed...

EDIT: "/mnt/utmp/codeblocks/usr/lib" it's already in LD_LIBRARY_PATH

nevermind... seems to have this problem only if launched from "screen"... it actually works from the Pandora... I need to have a better look at what exactly changes in the environment...

 

[PowerGod]

COOL !! Found the trick with screen !!

In the codeblock console you have to use

screen -d -m (to start "screen" in detached mode)
and then calling it from ssh with

screen -D -R The problem before was that launching "screen" without options from the terminal, was substituting the terminal itself with screen... so when it was detached by another console, it was closing the codeblock terminal and consequently the entire PND (with some exception for files currently in use) !!
Now the "screen -d -m" command launch the session in another thread that's using the same environment, but if it's closed to give connection to another client, the original terminal is still running, and so the entire PND.

I'm Happy now I can leave codeblocks always open and I can compile (and/or continue to compile) from every PC I can connect to.

 

[ptitSeb]

COOL !! Found the trick with screen !!


In the codeblock console you have to use


screen -d -m
(to start "screen" in detached mode)

and then calling it from ssh with


screen -D -R
The problem before was that launching "screen" without options from the terminal, was substituting the terminal itself with screen... so when it was detached by another console, it was closing the codeblock terminal and consequently the entire PND (with some exception for files currently in use) !!

Now the "screen -d -m" command launch the session in another thread that's using the same environment, but if it's closed to give connection to another client, the original terminal is still running, and so the entire PND.


I'm Happy now I can leave codeblocks always open and I can compile (and/or continue to compile) from every PC I can connect to.

Sound like a nice trick