torpor
hack hack hack, the little machines fight back
Install those packages! 
Cross-Compiling Is Bollocks! Toolchains Are Bollocks! Use Yo
- Thread starter torpor
- Start date
I have a problem, I can't install libgl1 in opkg, which means I can't install libgl-dev or libglu-dev so I can't compile mupen64plus, it's in the repo though: libgl1 1:7.2-r6.1 for armv7a (Ångström 2008.6 glibc armv7a base feed), so I'm stumped as to why it won't work, and I tried downloading the .ipk manually once before and installing it broke EGL_Init so mupen64plus wouldn't work at all. I'm not gonna try that again, but does anyone know why opkg won't install it?
This has been a problem with Angstrom for a long time. You need to compile mesa from source, or at least that's what I did. You can then install libglu-dev with opkg install --force-depends.Jdbye said:
Alternatively, you can remove the OpenGL code from the mupen64plus core. There's a patch to do this in the maemo repositories. OpenGL is only used for screenshots and a few other minor things, so it's not a huge problem to remove it.
Last edited by a moderator:
Where exactly can I find the patch? I found this: http://maemo.org/packages/source/vi...free_source/mupen64plus-arm/20100929-0maemo1/ but it's just 1 big diff file with all the changes (I did see something about making OpenGL optional in there though)Ari64 said:
Edit: I applied just the opengl patches, but my compiled mupen64plus segfaults after the logo, that's the same problem i had when i was cross compiling and manually removed the opengl parts, any idea why? How do you debug linux apps?
Edit2: From GDB trace
Code:
#0 0x408397ec in g_atomic_int_exchange_and_add ()
from /usr/lib/libglib-2.0.so.0
#1 0x40766b28 in g_object_ref () from /usr/lib/libgobject-2.0.so.0
#2 0x407e3b94 in g_list_foreach () from /usr/lib/libglib-2.0.so.0
#3 0x403bdfc0 in gtk_window_set_icon_list ()
from /usr/lib/libgtk-x11-2.0.so.0
#4 0x080cdf34 in ?? ()
Cannot access memory at address 0x0
#5 0x080cdf34 in ?? ()
Cannot access memory at address 0x0
Last edited by a moderator:
That's it. You should only need the first three patches.Jdbye said:
Crashes after what logo?Jdbye said:
I haven't seen anything like this. The GTK GUI works fine for me. What triggers this crash?Jdbye said:
Last edited by a moderator:
It's the default configuration files that were in the source, and the existing PND works fine.Ari64 said:
Edit: I did however notice that both QT4 and GTK+ were enabled in the makefile, could that cause problems?
Edit2: I got proper debug output now (enabled debugging symbols) and it looks like the GUI is indeed failing to load:
Code:
#0 0x408397ec in g_atomic_int_exchange_and_add ()
from /usr/lib/libglib-2.0.so.0
#1 0x40766b28 in g_object_ref () from /usr/lib/libgobject-2.0.so.0
#2 0x407e3b94 in g_list_foreach () from /usr/lib/libglib-2.0.so.0
#3 0x403bdfc0 in gtk_window_set_icon_list ()
from /usr/lib/libgtk-x11-2.0.so.0
#4 0x080cdf34 in create_mainWindow () at main/gui_gtk/main_gtk.c:1214
#5 0x080cf8a8 in gui_init (argc=0xbea61884, argv=0xbea61880)
at main/gui_gtk/main_gtk.c:100
#6 0x08003544 in main (argc=Cannot access memory at address 0xc6b538a0
) at main/main.c:1488
Last edited by a moderator:
torpor
hack hack hack, the little machines fight back
Hey .. umm .. guys .. you're getting mupen64plus debugging messages in my "bollocks to the toolchain" thread .. maybe you can start a new thread for this? I don't think this problem is toolchain related .. looks more like a NULL pointer dereference to me (just a glib look) ..
Sorry, I went kind of off topic there, I also posted in the Mupen64Plus thread but Ari64 responded here, so it just continued like that...torpor said:
I think it was toolchain related though, as paulguy's cross compiled one using the exact same source worked fine on my Pandora.
Last edited by a moderator:
Magic Sam
Forever Homebrew
Hi,
Thanks to this thread I managed to compile my first game on the Pandora !
Nothing new though, just the good ol' xrick we already have. I compiled it on my Debian laptop and knew it was quite simple and straight forward to do, that's why I have decided to compile it on the Pandora
I followed this thread, changed some package names here and there, had to symlink one gcc lib, and that's it ! I'll now toy with gcc options and have a look at PND making.
I'm not a dev, setting up a dev environment just scares the hell out of me !
Bye and thanks again !
Magic Sam
Thanks to this thread I managed to compile my first game on the Pandora !
Nothing new though, just the good ol' xrick we already have. I compiled it on my Debian laptop and knew it was quite simple and straight forward to do, that's why I have decided to compile it on the Pandora
I followed this thread, changed some package names here and there, had to symlink one gcc lib, and that's it ! I'll now toy with gcc options and have a look at PND making.
I'm not a dev, setting up a dev environment just scares the hell out of me !
Bye and thanks again !
Magic Sam
doesn't seem to want to install g++_4.3.3 ?
i end up getting a .bin file after running make command?
edit/
ah right need to run bin file using ./filename.bin
cool seems to have compiled okay evenb without installing g++_4.3.3!
hey my first compile for pandora, thanks torpor!
i end up getting a .bin file after running make command?
edit/
ah right need to run bin file using ./filename.bin
cool seems to have compiled okay evenb without installing g++_4.3.3!
hey my first compile for pandora, thanks torpor!
torpor
hack hack hack, the little machines fight back
peelie; great you got it sorted! I will update this thread soon for the new Hotfix ..
skeezix
Internal Development
I found of late that instead of opkg installing the works (as I reflash pretty much 2-3 times a week so its a pita for me to opkg install everythign over and over I just use a stuckie extend for Debian, and made a few GB overlay, and just apt-get installed the works there; that way it survives across reflashes (thogh dmittedly his debian extend is aging
Since this thread popped back up here, thought I'd note this anyway; after a bajillion opkg gcc and emac installs, I'm currently happy using the debian one for native builds. (and a swap js handy sometimes too when building big stuff.)
Mind you, using a debian-extend is no good for driver work or thigns that depend very tightly on such things.
jeff
I just use a stuckie extend for Debian, and made a few GB overlay, and just apt-get installed the works there; that way it survives across reflashes (thogh dmittedly his debian extend is aging Since this thread popped back up here, thought I'd note this anyway; after a bajillion opkg gcc and emac installs, I'm currently happy using the debian one for native builds. (and a swap js handy sometimes too when building big stuff.)
Mind you, using a debian-extend is no good for driver work or thigns that depend very tightly on such things.
jeff
torpor
hack hack hack, the little machines fight back
skeezix said:I found of late that instead of opkg installing the works (as I reflash pretty much 2-3 times a week so its a pita for me to opkg install everythign over and over
In my case, I think it works differently, since I have a "development Pandora" and a "user Pandora" arrangement .. My build-server Pandora doesn't need to be messed around with, much, and I build PND's on it for the user Pandora to test - if anything fails, its easy to fix this way. So I've got the reverse situation where I did a bunch of opkg stuff, and its now settled and stable on my developer Pandora, so I don't play with it.
Are you building PND's in that environment, and testing against stock user firmware? If so, thats quite neat, but I prefer to use the native development tools from opkg, instead of 'Debian->Angstrom' cross-compiling, even still ..
Last edited by a moderator:
skeezix
Internal Development
When I'm doing native, I have the two modes .. I tend to keep it in the debian extend (and run from there as well), since it survives the all too common flashes. I often will try it from native Angstrom as well for real testing -- I keep the OS unmodded so as to be closest to what average user has. So with the extend I can build natively (debian) and run natively (debian or Angstrom), and my Angstrom is unsullied by any mods whatsoever, which is pretty handy for such testing. (ie: No risk of having installed extra libs as a side effect of opkg everything).
I still tend to do most of my work on VM on a laptop/desktop/whatever, and scp (wifi or usbnet) the result to the pandora for testing, but when nothing else is around, I'll do the git pull, hack and git push right onboard (A number of PAndora firmware quick fixes and patches were done direct from my pandora with native emacs/git/gcc toolchain - it only seems appropriate that at least some of the firmware is built on the firmware, right
jeff
I still tend to do most of my work on VM on a laptop/desktop/whatever, and scp (wifi or usbnet) the result to the pandora for testing, but when nothing else is around, I'll do the git pull, hack and git push right onboard
(A number of PAndora firmware quick fixes and patches were done direct from my pandora with native emacs/git/gcc toolchain - it only seems appropriate that at least some of the firmware is built on the firmware, right jeff
torpor
hack hack hack, the little machines fight back
I have my Dev-Pandora mounted over USB_Network and I mount my dev folder over sshfs to my main Linux machine, from where I edit/code, and I have my Makefile set up to execute remotely over ssh, so its all pretty well integrated .. I don't think I'd easily change over to the Debian extend, at least not soon ..
skeezix
Internal Development
Oh certainly not; whatever works for you is the best approach, right? I just threw it out in case it tickled anyone elses fancy.
Also .. I used to do goofy union/aufs tricks, but Stuckie went way out of control with it. It just makes me giggle to see a union-set be so nuts
jeff
I just threw it out in case it tickled anyone elses fancy.Also .. I used to do goofy union/aufs tricks, but Stuckie went way out of control with it. It just makes me giggle to see a union-set be so nuts
jeff
Stuckie
Member
Well I've got some free time again, so lets see if I can abuse it much more
Probably about time I go and update some of my hacks a bit anyway.. I've also been storing up some feedback on various things, so if you've anything you'd like me to do, gimme a shout as now's the perfect time
I plan on having a go at this platform compo, so need an updated dev setup anyway.
Probably about time I go and update some of my hacks a bit anyway.. I've also been storing up some feedback on various things, so if you've anything you'd like me to do, gimme a shout as now's the perfect time
I plan on having a go at this platform compo, so need an updated dev setup anyway.
After reading this thread and trying some things I'm stuck with this question: My NAND only has 9 MB free (dunno why, I've only installed Hotfix 4 and community codecs. Everything else is (should) be on an SD-card), so can I install a native build environment on an SD-card while booting from NAND or should I install/run the firmware on an SD-card? In case of the former, can someone give a pointer how to get e.g. the gcc binary in the PATH when it's not installed on the NAND?
