Openal


Exophase said:
Is . included in the standard library search path? If so then you should be OK w/o adding anything, since the pnd is mounted to the cwd.

It didn't appear to work for me, I didn't use a .pnd but what I did was create a directory 'test' on the route of my SD card, and then copied my application.out file and library.so files to that directory, and executed the application file on the command line via: ./application.out - it moaned it couldn't find the .so files. So I used that LD environment variable to tell it to look in the current directory '.' and then it loaded up.

I think I might try setting rpath to be ./libs - if it accepts relative paths that seems like quite a nice solution. Out of interest, torpor, would you suggest I still use LD_PRELOAD inside the startup script, or is rpath already doing the same thing, only embedding that information into the elf?

Another, couple of no doubt stupid, question, does it matter what the extension of my files is? 'Application.out', 'Application', 'Application.elf'? Also, when I build this libs for Pandora, do they by default get built in 'release' mode, e.g. are they optimised with -O2/-O3 or whatever is appropriate? I am assuming so, but I know assumptions normally lead to no good! ;)

Thanks again for the help so far...

Steve
 
Last edited by a moderator:
Rockthesmurf said:
does it matter what the extension of my files is? 'Application.out', 'Application', 'Application.elf'?
No, in fact I think the Unix standard is that applications have no extension.
I have always just had small demos as "gcc -o main main.cpp", so the run command is "./main", and big ones get their own name and directory subtree, like "./bin/mmls"

Linux will figure out the executable type based on magic numbers. You can even execute scripts with "./" if they have the "#!/bin/interpreter" comment as the first line.
 
Last edited by a moderator:
Well, I tried:

Code:
arm-none-linux-gnueabi-gcc.exe openal-info.o libopenal.so -o openal-info.out -Wl,-rpath=libs

And created a directory structure:

Code:
.\openal-info.out
.\libs\libopenal.so
.\libs\libopenal.so.1
.\libs\libopenal.s.1.12

And it loads correctly without any LD_* environment variables, so that seems pretty neat!

Steve
 
Hoorah, I have just built alut (again using CMake + CodeSourcery), and then linked up a real basic sample that just lets me start/pause/stop a wave file that links against al/alut, with the -rpath linker flag - I copied the resultant files over to my SD, plonked it in my Pandora, and I now have sound coming through crystal clear. Success!

I think I am getting pretty close to being able to write a tutorials for how to build applications targeting at Pandora from a Windows PC now (without requiring VMs or anything like that).

Steve
 
Rockthesmurf said:
Trickyhero said:
We have the App Store(http://apps.open-pandora.org/) and The Archive (http://dl.openhandhelds.org/cgi-bin/pandora.cgi) for distribiting packages. All of the apps just go on your SD cards in the places that you want them in. And just in case if you want to know PS2 will never be possible on the Pandora. ;)

P.S Check the Wiki for a complete list of apps, and also the Archive has more games/apps.

I don't think you quite got what I was asking about, but thanks for your input anyway...

Exophase said:
You can get a lot of library binaries off of the Angstrom repository.

Ah this sounds more interesting, is there a way I can access this from Windows? Is there for instance a web search I can do in the repository, or do I need some mainly Linux program for it? I'm not really clued up on these things, so please forgive my ignorance.

Steve
Opps, sorry for treating you like an noob ;) It sounds like you know what your doing :)
 
Last edited by a moderator:
Opps, sorry for treating you like an noob ;) It sounds like you know what your doing :)

Ha - no no it is cool. I appreciate you trying to help. Not used a lot of Linux before so got a few bits and bobs to learn.

Steve
- Posted from my Pandora :)
 
Nice that you got it worked out Rockthesmurf .. I'm really interested in your progress, so any time you want to pack up a PND with a demo and samples included, would be good .. ;)

Please tell us whats next!

EDIT: btw, just wanted to say that I was recommending the LD_PRELOAD trick for debugging purposes only .. since you already worked out how to use -rpath, no problems now .. good job!
 
Back
Top