[Application] Code::Blocks and CommandLine Compile Everything

[Linux-SWAT]

Well, without this lib, you can't make girls astonished when saying: "hey, look at my up-to-date libstdc++".

 

[ptitSeb]

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?

IIRC, this newer libstdc++ came with the new GCC 4.7.2.I don't think I can downgrade the PND with the one in the Firmware without breaking c++ compilation.

Updating the Firmware, probably, but it's not my field of expertise...

 

[Loonie]

Well, without this lib, you can't make girls astonished when saying: "hey, look at my up-to-date libstdc++".

And they're all "ohmigah, check out that loser and his out-of-date libstdc++"

 

[Linux-SWAT]

Exactly, and this this something we don't want.

 

[foxblock]

Putting the lib inside the PND has not worked for me so far (probably because it is a standard lib and cannot be replaced as easily, or because I messed up).

Either way, setting the linker flag "-static-libstdc++" has been working fine for me for over a year now (since CodeSourcery ships with a newer stdc++ lib anyway). It ain't elegant and It will add about 400kb to your binary, but at least you can impress all those chicks (and actually get a running application, hey that's something).

 

[ptitSeb]

Putting the lib inside the PND has not worked for me so far (probably because it is a standard lib and cannot be replaced as easily, or because I messed up).

Either way, setting the linker flag "-static-libstdc++" has been working fine for me for over a year now (since CodeSourcery ships with a newer stdc++ lib anyway). It ain't elegant and It will add about 400kb to your binary, but at least you can impress all those chicks (and actually get a running application, hey that's something).

You have to put the lib inside a folder (lib for example) and add an


export LD_LIBRARY_PATH=/mnt/utmp/PNDname/lib:/usr/lib

for example....

With this, the libs you put inside the PND take precedence over the ones in the Firmware...

(Only problem you can have is when launching other shell script, when mixing sh and bash can be problemeatic I think, but I'm not a linux guru)

 

[foxblock]

I know, that's what I did (still did not work)

 

[sswam]

I don't think I can downgrade the PND with the one in the Firmware without breaking c++ compilation.

Updating the Firmware, probably, but it's not my field of expertise...

Ok, it's not a big deal, and I don't normally use C++ anyhow...

but probably should note it somewhere in big letters though, or people will wonder "WTF I can't build C++ programs".

Also the build actually failed with this ABI thing, suggests build environment is not set up to prefer your new libstdc++ over the one in the firmware.

LD_LIBRARY_PATH?  LD_PRELOAD?

Can or does your code::blocks include some README doc or release notes, with info like this, and a list of what libs and tools are included?

Maybe display it or offer to, on the first run...?

by the way, does code::block include Objective C and/or libs for it?  might be cool to impress hippy Apple chicks, although better find some program to build with it first!  Then, on to haskell, ocaml, mercury, and common lisp!  heheh or not.

I know, that's what I did (still did not work)

try also like:   LD_PRELOAD=./libstdc++.so

that should definitely work ... (cross fingers!)

 

[ptitSeb]

I don't understand one thing. Does the "stdlibc++.so.6" point is about compiling or running software?

For compiling, the command "sudo ldconfig -f /mnt/utmp/codeblocks/init/ld.so.cfg" MUST be launched for compilation to works (it is included in all launch script of code::blocks, but if you don't enter your password, compilation will fail).

For running, settings LD_LIBRARY_PATH in the launch script of the PND should work most of the time.

About ObjC, yes, it's now included, but I haven't tested it, so I don't know if it works.

 

[mcobit]

Edit: scratch that... Set wrong cflags.

 

[sswam]

hey again, I'm trying to build webkit-gtk.  glib-config and other glib dev tools are not found in the codeblocks PND, so pkg-config fails and configure fails.  Can you include them next time?  thanks

 

[ptitSeb]

hey again, I'm trying to build webkit-gtk.  glib-config and other glib dev tools are not found in the codeblocks PND, so pkg-config fails and configure fails.  Can you include them next time?  thanks

Ok, I'll try to include that. But, I cannot check now, but I think there is someting glib related already installed. But it's an old one, in sync with the glib actualy inside the Firmware (something like 2.18, I can't remember), and some new lib/software complains because it's too old.

And I reluctant to upgrade this glib lib, as it's too lowlevel in my taste.

But I can do an addipk if it's not included (did a quick test, it's missing, I will have to include it...)

 

[sswam]

Thanks for that.  Is there an ipk with those tools (glib-config, etc.) in it?

If so, could you kindly tell me what it's called / where I can get it?  It's in the angstrom unstable feed?

 

[ptitSeb]

Well. I upgrade the glib already in the future code::block PND. I needed it for some experiments...

I think I will do a build this weekend maybe. It will probably break the 1Go barrier this time I'm afraid.

About the "multi optionnal parts", I may try to render "wine" optionnal, for a start. It's not a big deal, something lke 60Mo save. But frst I have to see if there is an easy way to found/mount a PND with a script by just giving is ID, not location...

 

[pmprog]

About the "multi optionnal parts", I may try to render "wine" optionnal, for a start. It's not a big deal, something lke 60Mo save. But frst I have to see if there is an easy way to found/mount a PND with a script by just giving is ID, not location...

I was thinking you could request the user to put the PNDs in the "appdata" folder, you'd be then able to enumerate the filenames looking for PNDs, then mount them.

What do you think?

 

[ptitSeb]

What I have in mind, for wine in particular is:

I create a wineRT PND, fully package and autonomous. I even include some shortcut to "winemine", so by itself it's kind of usefull..

I modify the "takaeda-emulator" and "xmsol" package to have a test of existance of the wineRT PND at start (and using so simple symlink to use de mounted PND), as it's presence is mandatory for this package. The launch process is quite clear in my head, but I need a way to launch, or at least locate the PND.

For codeblocks, the package is not mandatory, but the process should be the same (I may just launch a small zenity temporary message to show that wine is not availble if not found).

I can, of course, use the PND inside an appdata, but that would only work for codeblocks, and not for other package that can use Wine

(by the way, I optimized wine a bit, I now have much better in takaeada, like 50fps without sound and 40fs with sound )

 

[PokeParadox]

In thr Pandora folder we could do with another system folder called "lib" or "common" or "shared" or something like that - any PNDs here would be treated as a shared resource and normal PNDs can "easily" look them up... o something.

 

[PowerGod]

I didn't follow all the previous posts, but I want to know if it's an issue or a feature the fact that when I close the PND, the system seems to maintain the environment it creates

Just because I have some applications that do strage things after Code::Blocks and I need to reboot to use them in the right way

 

[ptitSeb]

I didn't follow all the previous posts, but I want to know if it's an issue or a feature the fact that when I close the PND, the system seems to maintain the environment it creates

Just because I have some applications that do strage things after Code::Blocks and I need to reboot to use them in the right way

It's a feature I want to developpe: PND that use other PND content to run...

About your problem with some software (for example PNDManager) that doesn't work once code::block has been launched, create a dummy file inside appdata/codeblocks/init that is called clean_pnd

With that file, code::blocks will ask your password at exit (from IDE or CommandLine) and will unmount cleanly.

PS: Maybe it's a good idea to make this behavour the default one, instead of the optionnal one (and check for a unclean_pnd to not unmount cleanly?)

 

[PowerGod]

In my use-case the default cleaning should be useful, because I just use it to compile something and then I close it, but it's not a problem either, cool to have a way to enable it