[Application] Code::Blocks and CommandLine Compile Everything


I'd like to request Premake, it is a Lua build tool so it should be trivial to add I think...

A modular approach to this would definitely be appropriate.

The base pnd should only include the most common stuff and look for any additional features in its appdata folder.
 
I'd like to request Premake, it is a Lua build tool so it should be trivial to add I think...

A modular approach to this would definitely be appropriate.

The base pnd should only include the most common stuff and look for any additional features in its appdata folder.
Premake, I'll try to add that in my TODO.

About modular, yes, but it's not that easy. First, It's difficult to split in a "folder" approach (very few "component" can be splitted that way, Wine will work, but most of the libs (that make the size of this PND) go in the same "include", "share" and "lib" folder as the other). second point is, even if the PND is huge, it's compressed (thank's to squashfs), adding files on appdata will render the "full" package even bigger: uncompressed size is more than 4Go!!!

A good approach (in my point of view at least), would be a chain a PND, start one, automount the others, but I don't know how to do that for now (not just the automount, but also the autounmount at the end, and the mounting on specifics mount point inside the unionfs of the main PND, but it may not be PND, just squashfs ISO).
 
Last edited by a moderator:
I think your application is one of the best tool on Pandora. :)

Sadly i can't download your latest cause my internet connection is very slow.

Hope someone could find a way to split parts.
 
I just started up the CLI, and the following came up:
 


ldconfig: /mnt/utmp/codeblocks/usr/lib/libstdc++.so.6.0.16-gdb.py is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /mnt/utmp/codeblocks/usr/lib/libstdc++.so.6.0.17-gdb.py is not an ELF file - it has the wrong magic bytes at the start.
ldconfig: /mnt/utmp/codeblocks/usr/lib/libGLU.so.1 is not a symbolic link
ldconfig: /mnt/utmp/codeblocks/usr/lib/libGL.so.1 is not a symbolic link
ldconfig: /usr/lib/libpnd.so.1 is not a symbolic link
ldconfig: /usr/lib/libGLES2D.so.1 is not a symbolic link

Don't know if this is a problem
 
The "is not a symbolic link" are not a problem. They should be links instead of being the real files.
 
don't know if someone had the same problem before but my (short) search give no result. I can't compile with the normal C-Compiler, it throws an error that the libmpc,so.3 cannot be found or open. The project was created by the wizard. As compiler GNUGCC Compiler is selected.


-------------- Build: Debug in nocheinVersuch (compiler: GNU GCC Compiler)---------------

g++ -Wall -fexceptions -g -c /media/PANDORA/code/codeblocks/nocheinVersuch/main.cpp -o obj/Debug/main.o
/mnt/utmp/codeblocks/usr/libexec/gcc/armv7l-unknown-linux-gnueabi/4.7.2/cc1plus: error while loading shared libraries: libmpc.so.3: cannot open shared object file: No such file or directory
Process terminated with status 1 (0 minute(s), 0 second(s))
1 error(s), 0 warning(s) (0 minute(s), 0 second(s))
Are there any steps necessary to compile a program? Or had I selected the wrong compiler?
 
don't know if someone had the same problem before but my (short) search give no result. I can't compile with the normal C-Compiler, it throws an error that the libmpc,so.3 cannot be found or open. The project was created by the wizard. As compiler GNUGCC Compiler is selected.


-------------- Build: Debug in nocheinVersuch (compiler: GNU GCC Compiler)---------------

g++ -Wall -fexceptions -g -c /media/PANDORA/code/codeblocks/nocheinVersuch/main.cpp -o obj/Debug/main.o
/mnt/utmp/codeblocks/usr/libexec/gcc/armv7l-unknown-linux-gnueabi/4.7.2/cc1plus: error while loading shared libraries: libmpc.so.3: cannot open shared object file: No such file or directory
Process terminated with status 1 (0 minute(s), 0 second(s))
1 error(s), 0 warning(s) (0 minute(s), 0 second(s))
Are there any steps necessary to compile a program? Or had I selected the wrong compiler?
When the Command Line or Code::Blocks launch, it ask for your password. Be sure to input it correctly, or the "ldconfig" will not run correctly. In command line, if you want to relaunch it, type:



Code:
sudo ldconfig -f /mnt/utmp/codeblocks/init/ld.so.cfg
For code::blocks IDE, you have to exit and relaunch again.
 
ah okay. Problem is only the command line asks for a password not the IDE. Should i start it from console via pnd_run?
 
No, both need password, but ldconfig is not always needed. (but IDE use gksudo, command line just sudo).

First, there is a grace period with sudo: once password is entered, it stay active for some times.

Second, by default, code::blocks doesn't "undo" the ldconfig it does at start. So if you launched command line, enter password, and exit, if launch IDE it will not ask for password. And vice-versa. It reset only at reboot (note taht a few apps, for example the excelent PNDManager, don't work with code::blocks mounted). To avoid this (the always stay mounted), create a dummy file named "clean_pnd" inside appdata/codeblocks/init/ folder
 
Last edited by a moderator:
ah okay. Problem is only the command line asks for a password not the IDE. Should i start it from console via pnd_run?
Or maybe, you are using Buid 08 (v1.0.5.08)? There is a bug in this build, the sudo is all messed'up in the code::blocks launching :( If that's the case, I strongly advise you to upgrade (yes, 960Mo to download again, I'm sorry).

And yes, you can launch code::blocks from command line, just typing "codeblocks" lauch it.
 
Does this newest vesion of QT come with QGLWidget via the opengl implementation?
It is compiled with OpenGL (with GLES2) support. I launched some GL Demo and they works (But It's not fast, even If I'm pretty sure it's really GLES2 and not MesaGL, must be having GLES in a Window that kill perf).
 
ah okay. Problem is only the command line asks for a password not the IDE. Should i start it from console via pnd_run?
Or maybe, you are using Buid 08 (v1.0.5.08)? There is a bug in this build, the sudo is all messed'up in the code::blocks launching :( If that's the case, I strongly advise you to upgrade (yes, 960Mo to download again, I'm sorry).

And yes, you can launch code::blocks from command line, just typing "codeblocks" lauch it.
Okay, it works. I started the IDE via the codeblocks commandline. Thanks for your help :) Btw i use the latest version.
 
Last edited by a moderator:
I'll try recompiling gambatte and see how that works. QGLWidget would allow for Vsync and eliminate the screen tearing issue.
 
ah okay. Problem is only the command line asks for a password not the IDE. Should i start it from console via pnd_run?
Or maybe, you are using Buid 08 (v1.0.5.08)? There is a bug in this build, the sudo is all messed'up in the code::blocks launching :( If that's the case, I strongly advise you to upgrade (yes, 960Mo to download again, I'm sorry).

And yes, you can launch code::blocks from command line, just typing "codeblocks" lauch it.
Okay, it works. I started the IDE via the codeblocks commandline. Thanks for your help :) Btw i use the latest version.
Are you using xfce, minimenu, openbox?
 
I'll try recompiling gambatte and see how that works. QGLWidget would allow for Vsync and eliminate the screen tearing issue.
Looks like qgl is missing some header declarations or something as it is missing many definitions including glBegin and glEnd. Including GL/gl.h doesn't help because then there are conflicting definitions for other variables/functions
 
I'll try recompiling gambatte and see how that works. QGLWidget would allow for Vsync and eliminate the screen tearing issue.
Looks like qgl is missing some header declarations or something as it is missing many definitions including glBegin and glEnd. Including GL/gl.h doesn't help because then there are conflicting definitions for other variables/functions
I compiled with GLES2 support, not OpenGL. Looks like QGLWidget want GL only :( . So I'm sorry but it won't work (and you can select only one opengl backend)
 
I was not able to build BeebEm from the C++ source using code::blocks CLI,

it gave an error about a missing symbol, to do with the C++ ABI version.  IIRC it was expecting the symbol in libstdc++.

(sorry, can't quote exact message now, will edit it in later).

I can build BeebEm okay using my own "overlay" dev environment.

I was using a version of the code::blocks PND from a few weeks ago, not the very latest one.

This error shows that the library versions used in code::blocks might not match those in the firmware.

Did anyone else see an error like this?

Is it fixed with new code::blocks, or in the latest firmware?

(and thanks again for your great work on code::blocks it is very useful, and I will be voting for you!)
 
Last edited by a moderator:
The version of the libstdc++ inside code::blocks is newer than the one in the firmware. So when building a c++ software, you need to put the libstdc++.so.6 from code::blocks PND inside your new PND. But I'm sot sure that the answer to your question.
 
yes, that is the answer to my question... thank-you!

but shouldn't we use the same version as the firmware?

Or, should we update the one in the firmware?

Is there some new "killer feature" with the newer libstdc++, that we can't do without?
 
Back
Top