Code::Blocks with C/C++ Compiler

[Linux-SWAT]

Nice.


Do you intend to also ship SFML 2.0 in it ?

 

[ptitSeb]

It is not included now, but I will take a look and see if I can include it in a future version.


Is this library powerfull and/or easy to use?


But in the meantime, I suppose it is possible to install SFML somewhere, re-compile libraries with C/C++ Dev for example (or with a Terminal windows from within Code::Block), and setup Code::Block to use them. I haven't tested yet, but it will be my first step to include it anyway.

 

[Linux-SWAT]

It can be considered as the SDL replacement.


According to the best coder i know, it now has much more features and is actively maintained.


I just included it in my next Slackware release.

 

[ptitSeb]

And which one do suggest, the stable 1.6 or the 2.0RC? I haven't dig too much, so I'm not sure of the differences...


*EDIT*


Sorry, you allready mentionned it was v2.0...

 

[ptitSeb]

Hum... SFML is dependant on OpenAL, and I don't think it exist (for now) on the Pandora...

 

[Linux-SWAT]

I compiled it for Slackware.


http://slackware.openpandora.org/pandora/sl4p/sl4p-14.0/packages/extra/OpenAL-1.13-arm-2_SBo.tgz

 

[ptitSeb]

Oh, wouha, ok then, and thanks for the lib. I will look at this, but it may take a while, holidays are almost over for me, I will have less free-time for the Pandora.

 

[Linux-SWAT]

Don't worry, it was just a suggestion, i'm not a coder ;^).

 

[Loonie]

Excellent job, Seb. This is really usable now.


Does the compiler need additional setting up? I've tried to compile a simple test...

#include <iostream>

#include <stdio>


using namespace std;


int main()

{

    cout << "blah blah blah";

    return 0;

}

and compiling produces this:

Compiling: main.cpp
/mnt/utmp/codeblocks/usr/bin/../libexec/gcc/arm-angstrom-linux-gnueabi/4.3.3/cc1plus: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory

PS- My vote would go to including the SDL libs with the PND, as it is currently far more ubiquitous. I will have to give SFML a whirl some time.

 

[ptitSeb]

Oh


Strange. May be I miss something...


@Loonie, could try :


removing the "init" folder of the appdata/codeblock folder


or, another suggestion


run the cdevtools.pnd and leave it launched, I case I missed a link somewhere.


I'll try to reproduce the probem on my side too.

 

[ptitSeb]

On my Pandora, cdevtool.pnd is still mounted, and I can't umount it. So I'll have to reboot it, but I try to do something with lazarus and freepascal now, so it will have to wait a while...

 

[ptitSeb]

Without rebooting or removing the partition I used to build the PND, it works for me.


To reproduce :


1. I created a new Empty Project (I tried a console project, but it doesn't work properly, I will have to look at that too), in the appdata/home/projects folder, with a TestErreur name


2. I added a new file, main.cpp


3. Typed your sample


4. Compiled


5. It complained about <stdio> not found :wacko:


6. Changed to <stdio.h>


7. Compiled


8. Worked


I'll have to try again with no cdevtool mounted nor my dev' partition...

 

[Loonie]

Thanks for checking it out. I'll try some of those suggestions shortly. One other thing I'll try is to save the project on the main SD card that has the PND and appdata. Currently the source and project are saved to the second SD card in a dev directory.

 

[ptitSeb]

Saving on the appdata/codeblocks shound't be a problem, as long as you don't save in codeblocks directly. You have a appdata/codeblocks/home/projects setup for your projects ;-)

 

[ZXDunny]

I try to do something with lazarus and freepascal now

If you succeed, I'll be over the moon


I'll also echo the current requests for you to include SDL, please. If it's also included in Lazarus, I'll be quite chuffed


D.

 

[Loonie]

An update -


I downloaded and ran the cdevtools.pnd, then while the console was open, tried building the test case again. This time the compile worked. It failed to link, but that seems to be a problem on my end involving filenames.

Compiling: main.cppLinking executable: atest/usr/bin/ld: cannot open output file atest: Is a directorycollect2: ld returned 1 exit statusProcess terminated with status 1 (0 minutes, 2 seconds)1 errors, 0 warnings

So to summarize, your second suggestion to have cdevtools.pnd running has removed the problem, so there must indeed be a missing link somewhere in the codeblocks tools.


Edit: fixed above filename issue, example now compiles. Getting ever closer.

Compiling: main.cpp
Linking executable: atest


Output size is 7.81 KB


Process terminated with status 0 (0 minutes, 2 seconds)


0 errors, 0 warnings

 

[ptitSeb]

For SDL, I'll test, but it should be already include in the pnd. You should find all header in the SDL subdir, it should be plug'n play. But I will also test, try to a compile a sample somewhere...


For Lazarus (thanks ZXDunny, I didn't know Lazarus, and I'd love Delphi back in time, so that's cool to have that on the little Pandora)...


Well, I'm almost done.


I have it setup and running on my dev' partitition, but i still have to PND'd it. As a side note, this one is way bigger than Code::Blocks! The whole folder is 900Mo !!! I'm transferring all this to my PC to make the make_pnd faster...


@Loonie, I will look at this, and put Lazarus on hold, as I must understand what is going wrong before doing another PND. Thanks for the debugging...


Here is a little teaser for Lazarus...

 

[Loonie]

An addendum (to prevent the last post getting too big) -


CodeBlocks is now compiling without the cdevtools.pnd console running. I've noticed that in FileSystem/mnt/utmp there is now a cdevtools1000 directory, and it is locked, so it cannot now be deleted. It seems the CodeBlocks pnd might be linking to this directory instead of its own.


Edit - damn, I can't remove this directory at all now, not even in the console.

 

[ptitSeb]

@Loonie :


Yes, once cdevtools & codeblocks are launched, you have to reboot to be able to unmount /mnt/utmp/cdevtools1000.


I don't know if it's a "normal" behavior or if it's triggered by codeblocks pnd.


More checking involved...


The good new is, it's 100% reproductible.


The bad news: I have no clue right now. I keep digging.

 

[Loonie]

Ah, yes, after a reboot the directory could then be removed via console. And just to confirm, I ran CodeBlocks again after deleting that directory and sure enough:


"/mnt/utmp/codeblocks/usr/bin/../libexec/gcc/arm-angstrom-linux-gnueabi/4.3.3/cc1plus: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory".


SDL is included, eh. Good to know. I'll have to check that out. I'll mess around more with it with cdevtools mounted.


I'm very appreciative of your efforts. It's great to have CodeBlocks on the go, and it's quite surprising how usable it is.