Cross-Compiling Is Bollocks! Toolchains Are Bollocks! Use Yo


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?
 
Jdbye said:
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.

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:
Ari64 said:
Jdbye said:
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.

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.
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)

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
What could be causing this?
 
Last edited by a moderator:
Jdbye said:
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)
That's it. You should only need the first three patches.

Jdbye 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?
Crashes after what logo?

Jdbye said:
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
What could be causing this?
I haven't seen anything like this. The GTK GUI works fine for me. What triggers this crash?
 
Last edited by a moderator:
Ari64 said:
Jdbye said:
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)
That's it. You should only need the first three patches.

Jdbye 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?
Crashes after what logo?

Jdbye said:
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
What could be causing this?
I haven't seen anything like this. The GTK GUI works fine for me. What triggers this crash?
Right after the ascii logo in the terminal.
 
Last edited by a moderator:
Jdbye said:
Ari64 said:
I haven't seen anything like this. The GTK GUI works fine for me. What triggers this crash?
Right after the ascii logo in the terminal.
There must be something unusual about your setup, because the GUI is unmodified from mupen64plus v1.5, and works on many different Linux distributions. Try clearing your configuration files.
 
Last edited by a moderator:
Ari64 said:
Jdbye said:
Ari64 said:
I haven't seen anything like this. The GTK GUI works fine for me. What triggers this crash?
Right after the ascii logo in the terminal.
There must be something unusual about your setup, because the GUI is unmodified from mupen64plus v1.5, and works on many different Linux distributions. Try clearing your configuration files.
It's the default configuration files that were in the source, and the existing PND works fine.
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
0xc6b538a0 sounds like a bogus address, I have no idea why argc would point to that address.
 
Last edited by a moderator:
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) ..
 
torpor said:
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...
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:
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
 
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 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
 
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 :) 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 :)

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.

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.

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:
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 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 ..
 
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
 
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.
 
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?
 
Back
Top