Caanoo / WIZ Problems Getting Apps Built With Openwiz + Ikari Sdl To Run


HunterZ

Member
Joined
Feb 27, 2011
Messages
150
Location
Seattle
So I decided that I want to try some development on my new Wiz. Last night I set up the openwiz toolchain on my laptop's Ubuntu Linux 10.10 x64 install. I followed the instructions on the Wiz Wiki (http://gp2xwiz.co.uk/wiki/Setting_up_the_tool_chain_on_Linux), which had me install the toolchain to /opt/arm-openwiz-linux-gnu. I then added /opt/arm-openwiz-linux-gnu to the end of my $PATH. With this, I was able to compile the example program on the wiki.

Next, I tried building ikari's new SDL library sources (SDL-1.2.13-110312-Rotation.tar.gz) using the included instructions, except that I had to modify the configure line because it has some stuff in parentheses that doesn't work as written. I ended up using something like this (I may have used different --host and/or --build settings in the end):
Code:
NM=arm-openwiz-linux-gnu-nm LD=arm-openwiz-linux-gnu-ld CC=arm-openwiz-linux-gnu-gcc CXX=arm-openwiz-linux-gnu-g++ RANLIB=arm-openwiz-linux-gnu-ranlib AR=arm-openwiz-linux-gnu-ar ./configure --prefix=/opt/arm-openwiz-linux-gnu --enable-shared --enable-pthreads --enable-pthread-sem --enable-threads --disable-video-fbcon --disable-video-directfb --disable-video-x11 --disable-arts --disable-esd --disable-pulseaudio --enable-video --enable-video-gp2xwiz --host=arm-linux

It completed fine, so I ran make and then make install:
Code:
NM=arm-openwiz-linux-gnu-nm LD=arm-openwiz-linux-gnu-ld CC=arm-openwiz-linux-gnu-gcc CXX=arm-openwiz-linux-gnu-g++ RANLIB=arm-openwiz-linux-gnu-ranlib AR=arm-openwiz-linux-gnu-ar make
NM=arm-openwiz-linux-gnu-nm LD=arm-openwiz-linux-gnu-ld CC=arm-openwiz-linux-gnu-gcc CXX=arm-openwiz-linux-gnu-g++ RANLIB=arm-openwiz-linux-gnu-ranlib AR=arm-openwiz-linux-gnu-ar make install

That also completed fine.

I then tried building HopeZ's POWDER v114 source and the GPFCE source, both of which I modified to point at my openwiz toolchain install location. For GPFCE, I had to first download libpng, zlib and libcastor and integrate them into my toolchain install. Both POWDER and GPFCE built without errors, but when I tried running them on my Wiz from the launcher, they both just showed a black screen for a couple seconds and then went back to the Wiz main menu.

At that point last night I had to go to bed, but the only ideas I have so far are:
  • Maybe I need to re-build ikari's SDL now that I have libpng and zlib installed. I hadn't checked the configure log to see if SDL was looking for those.
  • I didn't grab torpor's libraries bundle that was mentioned on the wiki, so maybe I'm missing some other stuff that SDL or the toolchain needs but isn't complaining about for some reason?

It's also possible that maybe some of the libs weren't being statically linked to the binaries and that I needed to copy them onto the SD card as well, but I have no way to tell which ones I might need. I don't think this is the issue for GPFCE though, because the binary was about the same size as the binary from dl.openhandhelds.org and that version doesn't depend on dynamically-loaded library files as far as I can tell.

Any thoughts?
 
Update: Decided to give the official Wiz SDK a try instead. Managed to hack HopeZ's POWDER v114 source into compiling with it, and it runs! I might eventually try to get ikari's SDL to build with the SDK as well, but for now I'm happy to just have a working toolchain.

Compiling with the official SDK looks to be a bit more complicated than openwiz because they decided to put some stuff in the /opt/toolchain-wiz tree (like the Linux ARM gcc) and some in a separate /opt/toolchain-wiz/arm-linux tree (most of the libs). They also built sdl-config with some wacky default paths, so you have to override with --prefix=/opt/toolchain-wiz/arm-linux --exec-prefix=/opt/toolchain-wiz/arm-linux if you have makefiles that are using sdl-config with --cflags or --libs. Also, this sdl-config doesn't support --static-libs, which the POWDER makefile was trying to use, so I just changed it to --libs and it worked. It even seems to statically compile the libs in so that you don't need to copy them onto the SD.
 
Update 2: gpfce gives an odd error when I try to compile with the official Wiz toolchain:
Code:
/opt/toolchain-wiz/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld: ERROR: drivers/gp2x/asmutils.o uses FPA instructions, whereas fceu does not
/opt/toolchain-wiz/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld: failed to merge target specific data of file drivers/gp2x/asmutils.o
 
Update 3: Grabbed torpor's openwiz toolchain package from here on the forum and it builds GPFCE fine and runs on my Wiz. Since torpor's package uses a much newer version of GCC than the official GPH Wiz toolchain (4.2.4 versus 4.0.2) I'll probably stick with it, provided I can get POWDER to build as well (which is my next task).

Edit: POWDER built but crashed/froze on a black screen. I was able to determine that this was due to the fact that the GCC 4.2.x shared library libgcc_s.so.1 was being dynamically linked (even though everything else was being statically linked) but is not present in the Wiz NAND's /lib directory. I tried rebuilding with -static and got a segmentation fault / kernel too old error, so I rebuilt with dynamic linking and copied libgcc_s.so.1 to the same directory as the powder binary. This still didn't work because it wasn't in $LD_LIBRARY_PATH, so I edited the powder2x.gpe launcher script to temporarily add the current dir to $LD_LIBRARY_PATH like so:
Code:
#!/bin/sh
export HOME=`pwd`/pdata
cd
export POWDERLIB=$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
( ./powder > powder.log ) 2> error.log
export LD_LIBRARY_PATH=$POWDERLIB
sync
# return to the menu screen
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu

After all of the rigmarole it finally runs.

Edit 2: Now this is interesting: I added -lgcc to the linker command line arguments in the makefile and it was able to statically link libgcc into the powder binary such that I didn't need libgcc_s.so.1 anymore and it still runs on my Wiz. Neat!
 
Last edited by a moderator:
I see three problems here:

1) The old openwiz toolchain produces binaries that are not compatible with the Wiz!

The openwiz011909.tar.gz toolchain from openhandhelds.org produces binaries in FPA format, while all the Wiz runtime libs as well as Ikari's SDL libs are in VFP format.

2) You are mixing up native and host systems in your cross-compiling environment:

HunterZ said:
Compiling with the official SDK looks to be a bit more complicated than openwiz because they decided to put some stuff in the /opt/toolchain-wiz tree (like the Linux ARM gcc) and some in a separate /opt/toolchain-wiz/arm-linux tree (most of the libs).
That is exactly how it is supposed to be. Notice how the stuff that runs on the PC (compiler) is separated from the stuff that is supposed to run on the Wiz (libraries).

HunterZ said:
[...] ./configure --prefix=/opt/arm-openwiz-linux-gnu [...]
With this you are installing SDL into the root of the toolchain, which is wrong, as that is where the natives stuff lives. You should install libraries into another directory, not the toolchain directory. This way you cannot mess up your toolchain. Also, you never need to set include/linker paths into the toolchain directory, because the compiler has them built in already. This way you only need to need to point to your libraries, which also means you can use different toolchains without too much trouble (as long as they are compatible).

3) You are mixing different toolchains:

HunterZ said:
Update 2: gpfce gives an odd error when I try to compile with the official Wiz toolchain:
Code:
/opt/toolchain-wiz/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld: ERROR: drivers/gp2x/asmutils.o uses FPA instructions, whereas fceu does not/opt/toolchain-wiz/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld: failed to merge target specific data of file drivers/gp2x/asmutils.o
You probably did not clean up the build after switching toolchains. This looks like drivers/gp2x/asmutils.o was compiled with the old openwiz toolchain while your are linking using the GPH toolchain.
 
Last edited by a moderator:
Thanks for the feedback!

hmn said:
I see three problems here:

1) The old openwiz toolchain produces binaries that are not compatible with the Wiz!
I'm confused; why would a Wiz toolchain not produce Wiz binaries? Or are you referring to a dynamic linked library incompatibility rather than a binary-level incompatibility?

The openwiz011909.tar.gz toolchain from openhandhelds.org produces binaries in FPA format, while all the Wiz runtime libs as well as Ikari's SDL libs are in VFP format.
Is torpor's package based on the openwiz011909.tar.gz toolchain? For some reason I can get working binaries (including GPFCE) using the former, but I was not successful with the latter.

2) You are mixing up native and host systems in your cross-compiling environment:

HunterZ said:
Compiling with the official SDK looks to be a bit more complicated than openwiz because they decided to put some stuff in the /opt/toolchain-wiz tree (like the Linux ARM gcc) and some in a separate /opt/toolchain-wiz/arm-linux tree (most of the libs).
That is exactly how it is supposed to be. Notice how the stuff that runs on the PC (compiler) is separated from the stuff that is supposed to run on the Wiz (libraries).
Unfortunately it doesn't appear to be that logical: Torpor's openwiz toolchain has some "standard" GCC libs in one place, and stuff like SDL, libpng and zlib in the other, while the official GPH Wiz toolchain puts them all in one place. See below for gory details.

HunterZ said:
[...] ./configure --prefix=/opt/arm-openwiz-linux-gnu [...]
With this you are installing SDL into the root of the toolchain, which is wrong, as that is where the natives stuff lives. You should install libraries into another directory, not the toolchain directory. This way you cannot mess up your toolchain. Also, you never need to set include/linker paths into the toolchain directory, because the compiler has them built in already. This way you only need to need to point to your libraries, which also means you can use different toolchains without too much trouble (as long as they are compatible).
My understanding is that the binaries are all native (but in support of cross-compiling) and that the libraries are all meant to run on the Wiz, so there should be nothing to separate. Torpor's openwiz toolchain does seem to separate some includes/libs, while the official GPH Wiz toolchain lumps everything together:

In torpor's openwiz toolchain package, arm-openwiz-linux-gnu- prefixed cross-compiler binaries and sdl-config are in /opt/openwiz/toolchain/arm-openwiz-linux-gnu/bin/, and exact non-prefixed copies are in /opt/openwiz/toolchain/arm-openwiz-linux-gnu/arm-openwiz-linux-gnu/bin/

In terms of includes and libraries, the standard GCC stuff seems to be under /opt/openwiz/toolchain/arm-openwiz-linux-gnu/arm-openwiz-linux-gnu/:
Code:
ld-2.6.1.so               libc-2.6.1.so      libgcc_s.so.1     libiberty.a     libmudflap.so.0        libnsl-2.6.1.so         libnss_files.so.2        libpcprofile.so      libSegFault.so       libssp.so.0.0.0     libsupc++.a
ld-linux.so.2             libcrypt-2.6.1.so  libgomp.a         libm-2.6.1.so   libmudflap.so.0.0.0    libnsl.so.1             libnss_hesiod-2.6.1.so   libpthread-2.6.1.so  libssp.a             libstdc++.a         libsupc++.la
ldscripts                 libcrypt.so.1      libgomp.la        libmemusage.so  libmudflapth.a         libnss_compat-2.6.1.so  libnss_hesiod.so.2       libpthread.so.0      libssp.la            libstdc++.la        libthread_db-1.0.so
libanl-2.6.1.so           libc.so.6          libgomp.so        libm.so.6       libmudflapth.la        libnss_compat.so.2      libnss_nis-2.6.1.so      libresolv-2.6.1.so   libssp_nonshared.a   libstdc++_pic.a     libthread_db.so.1
libanl.so.1               libdl-2.6.1.so     libgomp.so.1      libmudflap.a    libmudflapth.so        libnss_dns-2.6.1.so     libnss_nisplus-2.6.1.so  libresolv.so.2       libssp_nonshared.la  libstdc++.so        libutil-2.6.1.so
libBrokenLocale-2.6.1.so  libdl.so.2         libgomp.so.1.0.0  libmudflap.la   libmudflapth.so.0      libnss_dns.so.2         libnss_nisplus.so.2      librt-2.6.1.so       libssp.so            libstdc++.so.6      libutil.so.1
libBrokenLocale.so.1      libgcc_s.so        libgomp.spec      libmudflap.so   libmudflapth.so.0.0.0  libnss_files-2.6.1.so   libnss_nis.so.2          librt.so.1           libssp.so.0          libstdc++.so.6.0.9

...and the nonstandard stuff (SDL etc.) is under /opt/openwiz/toolchain/arm-openwiz-linux-gnu/:
Code:
ben@shodan:~/Downloads/wiz/powder114_src/port/gp2x/Powder2X$ ls /opt/openwiz/toolchain/arm-openwiz-linux-gnu/lib
gcc                             libFLAC++.a            libhistory.so.5.2   libmad.a                  libmpeg2.so         libreadline.so             libSDL_mixer.a           libungif.a               libvorbis.la
imlib2                          libFLAC.la             libiberty.a         libmad.la                 libmpeg2.so.0       libreadline.so.5           libSDL_mixer.la          libungif.la              libvorbis.so
libarm-openwiz-linux-gnu-sim.a  libFLAC++.la           libiconv.a          libmad.so                 libmpeg2.so.0.1.0   libreadline.so.5.2         libSDL_mixer.so          libungif.so              libvorbis.so.0
libbz2.a                        libFLAC.so             libiconv.la         libmad.so.0               libncurses.a        libSDL-1.2.so.0            libSDL.so                libungif.so.4            libvorbis.so.0.4.0
libcastor.a                     libFLAC++.so           libiconv.so         libmad.so.0.2.1           libncurses++.a      libSDL-1.2.so.0.11.2       libSDL_svg-1.1.so.8      libungif.so.4.1.6        libxml2.a
libcastor_extra.a               libFLAC++.so.6         libiconv.so.2       libmenu.a                 libncurses_g.a      libSDL.a                   libSDL_svg-1.1.so.8.0.1  libunicodefont.a         libxml2.la
libcastor_extra.so.0.1          libFLAC++.so.6.2.0     libiconv.so.2.4.0   libmenu_g.a               libogg.a            libSDL_gfx.a               libSDL_svg.a             libunicodefont.so        libxml2.so
libcastor.so.0.1                libFLAC.so.8           libid3tag.a         libmikmod.a               libogg.la           libSDL_gfx.la              libSDL_svg.la            libunicodefont.so.1.0.1  libxml2.so.2
libcharset.a                    libFLAC.so.8.2.0       libid3tag.la        libmikmod.la              libogg.so           libSDL_gfx.so              libSDL_svg.so            libvorbis.a              libxml2.so.2.7.2
libcharset.la                   libform.a              libid3tag.so        libmikmod.so              libogg.so.0         libSDL_gfx.so.0            libSDL_ttf-2.0.so.0      libvorbisenc.a           libz.a
libcharset.so                   libform_g.a            libid3tag.so.0      libmikmod.so.2            libogg.so.0.5.3     libSDL_gfx.so.0.0.17       libSDL_ttf-2.0.so.0.6.3  libvorbisenc.la          libz.so
libcharset.so.1                 libfreetype.a          libid3tag.so.0.3.0  libmikmod.so.2.0.4        libpanel.a          libSDL_image-1.2.so.0      libSDL_ttf.a             libvorbisenc.so          libz.so.1
libcharset.so.1.0.0             libfreetype.la         libImlib2.a         libmpcdec.a               libpanel_g.a        libSDL_image-1.2.so.0.1.6  libSDL_ttf.la            libvorbisenc.so.2        libz.so.1.2.3
libexpat.a                      libfreetype.so         libImlib2.la        libmpcdec.la              libpng12.a          libSDL_image.a             libSDL_ttf.so            libvorbisenc.so.2.0.3    pkgconfig
libexpat.la                     libfreetype.so.6       libImlib2.so        libmpcdec.so              libpng12.la         libSDL_image.la            libtiff.a                libvorbisfile.a          preloadable_libiconv.so
libexpat.so                     libfreetype.so.6.3.18  libImlib2.so.1      libmpcdec.so.5            libpng12.so         libSDL_image.so            libtiff.la               libvorbisfile.la         xml2Conf.sh
libexpat.so.1                   libgif.a               libImlib2.so.1.4.2  libmpcdec.so.5.0.2        libpng12.so.0       libSDL_inifile.a           libtiff.so               libvorbisfile.so
libexpat.so.1.5.2               libgif.la              libjpeg.a           libmpeg2.a                libpng12.so.0.33.0  libSDL_inifile.so          libtiff.so.3             libvorbisfile.so.3
libfaad.a                       libgif.so              libjpeg.la          libmpeg2convert.a         libpng.a            libSDL_inifile.so.1        libtiff.so.3.8.2         libvorbisfile.so.3.2.0
libfaad.la                      libgif.so.4            libjpeg.so          libmpeg2convert.la        libpng.la           libSDL_inifile.so.1.0.0    libtiffxx.a              libvorbisidec.a
libfaad.so                      libgif.so.4.1.6        libjpeg.so.62       libmpeg2convert.so        libpng.so           libSDL.la                  libtiffxx.la             libvorbisidec.la
libfaad.so.0                    libhistory.a           libjpeg.so.62.0.0   libmpeg2convert.so.0      libpng.so.3         libSDLmain.a               libtiffxx.so             libvorbisidec.so
libfaad.so.0.0.0                libhistory.so          libjpeg.so.7        libmpeg2convert.so.0.0.0  libpng.so.3.33.0    libSDL_mixer-1.2.so.0      libtiffxx.so.3           libvorbisidec.so.1
libFLAC.a                       libhistory.so.5        libjpeg.so.7.0.0    libmpeg2.la               libreadline.a       libSDL_mixer-1.2.so.0.2.6  libtiffxx.so.3.8.2       libvorbisidec.so.1.0.2
My guess is that this was done because torpor added the nonstandard libs to the base toolchain and wanted to keep them separate to make it easier to incorporate external updates to either the base toolchain and/or the nonstandard libs without munging things.

I should also mention that the official GPH Wiz toolchain is similar, with arm-linux- prefixed cross-compiler binaries under /opt/toolchain-wiz/bin/ and exact non-prefixed copies are under /opt/toolchain-wiz/arm-linux/bin/. The big difference here is that GPH put sdl-config, the standard GCC libs *and* the nonstandard libs all under /opt/toolchain-wiz/arm-linux/:
Code:
crt1.o                    libc.so                 libgcc_s.so.1       libm.so.6                libnss_nisplus.so       librt-2.3.6.so             libthread_db-1.0.so     libXaw.so.7.0.0         libXfixes.so.0.2.0    libXmuu.so.0.1.0
crti.o                    libc.so.6               libiberty.a         libmudflap.a             libnss_nisplus.so.2     librt.a                    libthread_db.so         libXcalibrate.a         libXfont.a            libXpm.a
crtn.o                    libc.so_orig            libICE.a            libmudflap.dir           libnss_nis.so           librt.so                   libthread_db.so.1       libXcalibrate.la        libXfont.la           libXpm.la
gconv                     libdl-2.3.6.so          libICE.la           libmudflap.la            libnss_nis.so.2         librt.so.1                 libts-0.0.so.0          libXcalibrate.so        libXfont.so           libXpm.so
gcrt1.o                   libdl.a                 libICE.so           libmudflap.so            libogg.a                libSDL-1.2.so.0            libts-0.0.so.0.1.1      libXcalibrate.so.0      libXfont.so.1         libXpm.so.4
ld-2.3.6.so               libdl.so                libICE.so.6         libmudflap.so.0          libogg.la               libSDL-1.2.so.0.11.1       libts.la                libXcalibrate.so.0.0.0  libXfont.so.1.4.1     libXpm.so.4.5.0
ld-linux.so.2             libdl.so.2              libICE.so.6.3.1     libmudflap.so.0.0.0      libogg.so               libSDL_gfx.a               libts.so                libXcomposite.a         libXft.a              libXrandr.a
ldscripts                 libexpat.a              libid3tag.a         libmudflapth.a           libogg.so.0             libSDL_gfx.la              libutil-2.3.6.so        libXcomposite.la        libXft.la             libXrandr.la
libanl-2.3.6.so           libexpat.la             libid3tag.la        libmudflapth.la          libogg.so.0.5.3         libSDL_image-1.2.so.0      libutil.a               libXcomposite.so        libXft.so             libXrandr.so
libanl.a                  libexpat.so             libid3tag.so        libmudflapth.so          libpcprofile.so         libSDL_image-1.2.so.0.1.5  libutil.so              libXcomposite.so.1      libXft.so.2           libXrandr.so.2
libanl.so                 libexpat.so.0           libid3tag.so.0      libmudflapth.so.0        libpng12.a              libSDL_image.a             libutil.so.1            libXcomposite.so.1.1.0  libXft.so.2.1.2       libXrandr.so.2.0.1
libanl.so.1               libexpat.so.0.5.0       libid3tag.so.0.3.0  libmudflapth.so.0.0.0    libpng12.la             libSDL_image.la            libvorbisidec.a         libXdamage.a            libXinerama.a         libXrender.a
libBrokenLocale-2.3.6.so  libfontcache.a          libieee.a           libnsl-2.3.6.so          libpng12.so             libSDL_image.so            libvorbisidec.la        libXdamage.la           libXinerama.la        libXrender.la
libBrokenLocale.a         libfontcache.la         libjpeg.a           libnsl.a                 libpng12.so.0           libSDL.la                  libvorbisidec.so        libXdamage.so           libXinerama.so        libXrender.so
libBrokenLocale.so        libfontcache.so         libjpeg.la          libnsl.so                libpng12.so.0.0.0       libSDLmain.a               libvorbisidec.so.1      libXdamage.so.0         libXinerama.so.1      libXrender.so.1
libBrokenLocale.so.1      libfontcache.so.0       libjpeg.so          libnsl.so.1              libpng.a                libSDL.so                  libvorbisidec.so.1.0.2  libXdamage.so.0.1.0     libXinerama.so.1.0.1  libXrender.so.1.3.0
libbsd-compat.a           libfontcache.so.0.0.0   libjpeg.so.62       libnss_compat-2.3.6.so   libpng.la               libSegFault.so             libX11.a                libXdmcp.a              libxkbfile.a          libXt.a
libc-2.3.6.so             libfontconfig.a         libjpeg.so.62.0.0   libnss_compat.so         libpng.so               libSM.a                    libX11.la               libXdmcp.la             libxkbfile.la         libXt.la
libc.a                    libfontconfig.la        liblzo2.a           libnss_compat.so.2       libpng.so.3             libSM.la                   libX11.so               libXdmcp.so             libxkbfile.so         libXt.so
libcastor.a               libfontconfig.so        liblzo2.la          libnss_dns-2.3.6.so      libpng.so.3.0.0         libSM.so                   libX11.so.6             libXdmcp.so.6           libxkbfile.so.1       libXt.so.6
libcastor_extra.a         libfontconfig.so.1      libm-2.3.6.so       libnss_dns.so            libpthread-0.10.so      libSM.so.6                 libX11.so.6.2.1         libXdmcp.so.6.0.0       libxkbfile.so.1.0.1   libXt.so.6.0.1
libcastor_extra.so        libfontconfig.so.1.0.4  libm.a              libnss_dns.so.2          libpthread.a            libSM.so.6.0.1             libXau.a                libXext.a               libXmu.a              libz.so
libcastor_extra.so.0.1    libfreetype.a           libmad.a            libnss_files-2.3.6.so    libpthread_nonshared.a  libstdc++.a                libXau.la               libXext.la              libXmu.la             libz.so.1
libcastor.so              libfreetype.la          libmad.la           libnss_files.so          libpthread.so           libstdc++.dir              libXau.so               libXext.so              libXmu.so             libz.so.1.2.2
libcastor.so.0.1          libfreetype.so          libmad.so           libnss_files.so.2        libpthread.so.0         libstdc++.la               libXau.so.6             libXext.so.6            libXmu.so.6           Mcrt1.o
libc_nonshared.a          libfreetype.so.6        libmad.so.0         libnss_hesiod-2.3.6.so   libpthread.so_orig      libstdc++.so               libXau.so.6.0.0         libXext.so.6.4.1        libXmu.so.6.2.1       pkgconfig
libcrypt-2.3.6.so         libfreetype.so.6.3.8    libmad.so.0.2.1     libnss_hesiod.so         libresolv-2.3.6.so      libstdc++.so.6             libXaw.a                libXfixes.a             libXmuu.a             Scrt1.o
libcrypt.a                libg.a                  libmcheck.a         libnss_hesiod.so.2       libresolv.a             libstdc++.so.6.0.6         libXaw.la               libXfixes.la            libXmuu.la            ts
libcrypt.so               libgcc_s.dir            libmemusage.so      libnss_nis-2.3.6.so      libresolv.so            libsupc++.a                libXaw.so               libXfixes.so            libXmuu.so            X11
libcrypt.so.1             libgcc_s.so             libm.so             libnss_nisplus-2.3.6.so  libresolv.so.2          libsupc++.la               libXaw.so.7             libXfixes.so.0          libXmuu.so.0          Xli

3) You are mixing different toolchains:

HunterZ said:
Update 2: gpfce gives an odd error when I try to compile with the official Wiz toolchain:
Code:
/opt/toolchain-wiz/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld: ERROR: drivers/gp2x/asmutils.o uses FPA instructions, whereas fceu does not/opt/toolchain-wiz/bin/../lib/gcc/arm-linux/4.0.2/../../../../arm-linux/bin/ld: failed to merge target specific data of file drivers/gp2x/asmutils.o
You probably did not clean up the build after switching toolchains. This looks like drivers/gp2x/asmutils.o was compiled with the old openwiz toolchain while your are linking using the GPH toolchain.
I wondered if that was the case when I first saw it as well, so I explicitly checked that that .o was deleted before one of my compile attempts. It was definitely built with the official GPH Wiz toolchain, yet it still gave me that error. Either the official Wiz toolchain's assembler is broken, or the assembly source itself is incompatible with the toolchain, or I'm screwing it up some other way. If you can get GPFCE to compile and run using the stock GPH Wiz toolchain (plus libcastor), I'd be curious to see a tarball of your source and the commands you used.


The upside of using the official toolchain is that you can dynamically link and have it use the libs on the NAND. The downside is that the compiler and libs are much, much older than the openwiz ones, and they don't seem to be able to build some stuff like GPFCE. On the whole, it seems better to me to use the openwiz toolchain and statically link when possible, as the result is likely to be better optimized and less error-prone.
 
Last edited by a moderator:
I just built libcastor and gpfce (sources taken from openhandhelds.orh) using the GPH toolchain and these modified Makefiles: http://pastie.org/1693017

Edit: The Makefiles assume SDK_DIR to be set to the GPH_SDK directory, and CASTOR_DIR to the libcastor directioy...

There are indeed changes in the compiler flags that need to be made in order to get the correct float instructions! (ie remove -msoft-float OR add -mfpu=vfp). Also the source release of gpfce does not compile out of the box because the Makefile assumes it is operating on a SVN working copy when it tries to generate "rev.h"

BTW: When did this happen? :)
 
hmn said:
I just built libcastor and gpfce (sources taken from openhandhelds.orh) using the GPH toolchain and these modified Makefiles: http://pastie.org/1693017

Edit: The Makefiles assume SDK_DIR to be set to the GPH_SDK directory, and CASTOR_DIR to the libcastor directioy...

There are indeed changes in the compiler flags that need to be made in order to get the correct float instructions! (ie remove -msoft-float OR add -mfpu=vfp).
Thanks! I had tried messing with those flags but didn't hit on the right combination because I didn't know what I was doing. Good to know I had the right idea though. Is there likely to be any performance advantage to compiling apps with a VFP toolchain versus an FPA one (or with one toolchain versus the other in general, for that matter)? As far as I can tell, VFP is newer but it may arbitrary when using software floating point emulation (I'm assuming the Wiz has no hardware FPU, as I can't find anything on it).

Also the source release of gpfce does not compile out of the box because the Makefile assumes it is operating on a SVN working copy when it tries to generate "rev.h"
Weird, I was able to get the GPFCE source package from dl.openhandhelds.org to compile with torpor's openwiz toolchain package just by putting the correct toolchain paths in the makefile. Were you working with a copy from somewhere else?

BTW: When did this happen? :)
Sometime in the past week or so. I made another thread here mentioning it.
 
Last edited by a moderator:
I use the Open2x SDK for GP2X to build Wiz binaries. I couldn't find any links to prebuilt packages (I think they used to be on SourceForge and open2x.org but not anymore), so I uploaded the one I have to DropBox: https://www.dropbox.com/s/n6kadszy02d28bh/open2x.tar.bz2

Extract the tar.bz2 archive to /opt, then try this makefile that should build MyGame.wiz.gpe from MySourceFile.c:

Code:
OPEN2X = /opt/open2x/gcc-4.1.1-glibc-2.3.6

LIBS = -L$(OPEN2X)/lib \
       -L$(OPEN2X)/arm-open2x-linux/lib \
       -lpng12 \
       -lz \
       -lSDL_mixer \
       -lsmpeg \
       -lSDL \
       -lpthread \
       -lm \
       -ldl

CFLAGS = `$(OPEN2X)/bin/sdl-config --cflags` \
         -I$(OPEN2X)/include \
         -I$(OPEN2X)/arm-open2x-linux/include

PREFIX := arm-open2x-linux-

export PATH    := $(OPEN2X)/bin:$(PATH)
export CC      := $(PREFIX)gcc
export CXX     := $(PREFIX)g++
export AS      := $(PREFIX)as
export AR      := $(PREFIX)ar
export OBJCOPY := $(PREFIX)objcopy
export READELF := $(PREFIX)readelf
export STRIP   := $(PREFIX)strip

TARGET_BINARY = MyGame.wiz.gpe

all : $(TARGET_BINARY)

$(TARGET_BINARY) :
	$(CC) -o $(TARGET_BINARY) MySourceFile.c $(CFLAGS) $(LIBS)

Good luck and let us know how this works.
 
Well the official GP2X Wiz toolchain works for me, but it's pretty old. Is this open2x toolchain any newer?

BTW, I tried installing hmn's GCC 4.7.3 toolchain from the other thread, then built Ikari's SDL and its dependencies. The OhBoy binary built from that doesn't run on my Wiz either (just a black screen and then return to gmenu2x).

I suppose it's possible that the OhBoy source I'm trying is messed up. Is there a simple test program that shows something on the Wiz screen that I can use to test these toolchains?

Edit: Make a statically-linked hello world program and ran it in termula2x, and it works fine. Could be that I need to use static linking for everything, or that something is wrong with my SDL.
 
Last edited:
Try this, it should fill the screen with white pixels:

Code:
#include <SDL.h>

int main(int Argc, const char** Argv)
{
    SDL_Init(SDL_INIT_VIDEO);
    SDL_Surface* screen = SDL_SetVideoMode(320, 240, 16, SDL_SWSURFACE);
    memset(screen->pixels, 0xff, 2 * 320 * 240);
    SDL_Flip(screen);
    while(1) continue;
}
[doublepost=1483058111,1483057951][/doublepost]
Edit: Make a statically-linked hello world program and ran it in termula2x, and it works fine. Could be that I need to use static linking for everything, or that something is wrong with my SDL.
If I remember well the OpenWiz toolchain was made to create apps for the unreleased OpenWiz firmware. It could be that the toolchain has some libraries whose versions are incompatible with the ones on the stock GPH firmware, so using static linking fixes this.
 
Thanks, I'll try that.

FYI, I was referring to hmn's GCC 4.7.3 toolchain in regards to the test program.

I changed OhBoy to statically link as much as possible, and now it starts up but has a garbled screen. This could be because I'm trying to compile hi-ban's fork, and that Wiz support may have rotted in his source tree.

Edit: Test program works fine. I guess this means OhBoy's source needs some tweaking. Thanks for the help!

Edit 2: Got the same garbled screen to show up in OhBoy using dynamic linking, by following the library dependencies all the way down via readelf, and then copying them all into the same folder as the ohboy binary. No idea why the garbled screen is happening so far - I bypassed the Wiz-specific SDL video setup code, but there was no difference. The rest of the setup code looks like the test program from alxm, except that it doesn't seem to call SDL_Flip() (which shouldn't matter since double buffering is not requested?).
 
Last edited:
What do you mean by the screen being garbled? Some Wiz applications set the screen to portrait mode 240x320 to avoid tearing, then rotate and draw a landscape buffer to it every frame, or use custom drawing routines that work in portrait mode. Maybe the problem is related to that.

Could you try this, it should fill the top half of the screen white:

Code:
#include <SDL.h>

int main(int Argc, const char** Argv)
{
   SDL_Init(SDL_INIT_VIDEO);
   SDL_Surface* screen = SDL_SetVideoMode(320, 240, 16, SDL_SWSURFACE);
   memset(screen->pixels, 0xff, 2 * 320 * 120);
   memset((char*)screen->pixels + 2 * 320 * 120, 0x00, 2 * 320 * 120);
   SDL_Flip(screen);
   while(1) continue;
}

I don't think the screen would get updated without calling SDL_Flip, regardless of whether or not you specify double buffering. Maybe that's different in the custom SDL you're using, I only used the one that ships with the GPH firmware.
 
I'll try that when I get a chance. Maybe I'll try to take a picture of the garbled screen using my phone.

OhBoy doesn't set a weird video mode:
Code:
screen = SDL_SetVideoMode(320, 240, 16, SDL_SWSURFACE);

It did have some special video setup code for Wiz, but I tried bypassing it and saw no change in behavior:
Code:
#include <SDL/SDL.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#define FBIO_MAGIC 'D'
#define FBIO_LCD_CHANGE_CONTROL _IOW(FBIO_MAGIC, 90, unsigned int[2])
#define LCD_DIRECTION_ON_CMD 5 /* 320x240 */
#define LCD_DIRECTION_OFF_CMD 6 /* 240x320 */

#if WIZ
SDL_Surface *WIZ_SetVideoMode(int width, int height, int bitsperpixel, Uint32 flags){
   SDL_Surface *s;
   s = SDL_SetVideoMode(width, height, bitsperpixel, flags);
   if(s){
       unsigned int send[2];int fb_fd = open("/dev/fb0", O_RDWR);
       send[0] = LCD_DIRECTION_OFF_CMD;
       ioctl(fb_fd, FBIO_LCD_CHANGE_CONTROL, &send);
       close(fb_fd);
   }
   return s;
}
#endif
 
Update:

The promised screenshot is below.

Some interesting notes:
  • I compiled the test programs that come with libSDL and put one on my Wiz, and it ran fine (except that the mouse cursor coordinates seemed to be rotated 90 degrees from where I was touching the screen with the stylus).
  • I just noticed that the background image on the OhBoy screen below looks fine, but the menu text is garbled (and I don't see any pixels change when I try to interact with it via the D-pad or buttons).
I guess this means that OhBoy's overall SDL init is occurring correctly, but something is going on farther down the line that is breaking the menus?

jjYlu4L.jpg

[doublepost=1484957453,1484953429][/doublepost]Tried to build Bitrider's old OhBoy release for Wiz, and the same thing happens except that the background is corrupted too and the menu responds. If I launch a game, it run but looks similarly corrupted.

I tried dropping in Ikari's pre-build SDL lib over the top of the one I built from his source, and the result is the same.

I wonder if the Wiz ports of OhBoy have some deep Wiz-specific hacks in them that are conflicting with deep Wiz-specific hacks in Ikari's SDL release?
 
1) The old openwiz toolchain produces binaries that are not compatible with the Wiz!

The openwiz011909.tar.gz toolchain from openhandhelds.org produces binaries in FPA format, while all the Wiz runtime libs as well as Ikari's SDL libs are in VFP format.

This is actually not completey correct. The firmware is completely inconsistent about this (hey, thats GPH for you). Here is the relevant output from (arm-...) objdump:
Code:
Kernel modules:
     10 private flags = 200: [APCS-32] [FPA float format] [software FP]
Firmware libraries:
     24 private flags = 2: [APCS-32] [FPA float format] [has entry point]
     49 private flags = 602: [APCS-32] [VFP float format] [software FP] [has entry point]
So it is possible to mix FPA and VFP code - although I'm pretty sure this will lead to problems if you pass floats/doubles across library boundaries.

As for ohboy, the binary from the archive is in FPA format (as everything produced by the openwiz toolchain by default), but dynamically links against libSDL.so from the firmware, which is in VFP format.

The promised screenshot is below.
This looks like the font rendering is broken. My guess is that you build ohboy against a version of freetype2 which is not binary compatible with the libfreetype that is in the firmware. Actually, one cannot build against the "correct" version of freetype2, because it is broken in the SDK (ft2build.h is missing).

With a "repaired" version of the freetype2 headers, I was able to build ohboy (from the sources in the archive, with trivial modifications) with the SDK and my 4.7.3 toolchain, and it is running without issues so far.
 
Last edited:
Back
Top