1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Dismiss Notice

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

Discussion in 'General Discussions' started by HunterZ, Mar 16, 2011.

  1. HunterZ

    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?
     
    Tags:
  2. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    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.
     
  3. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    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
     
  4. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    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: Dec 19, 2015
  5. hmn

    hmn Member

    Joined:
    Mar 8, 2010
    Messages:
    192
    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:

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

    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:

    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: Dec 17, 2015
  6. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    Thanks for the feedback!

    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?

    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.

    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.

    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
    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: Dec 17, 2015
  7. hmn

    hmn Member

    Joined:
    Mar 8, 2010
    Messages:
    192
    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? :)
     
  8. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    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).

    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?

    Sometime in the past week or so. I made another thread here mentioning it.
     
    Last edited by a moderator: Dec 17, 2015
  9. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
  10. alxm

    alxm Still making GP2X games!

    Joined:
    Jul 11, 2013
    Messages:
    139
    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.
     
  11. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    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: Dec 30, 2016
  12. alxm

    alxm Still making GP2X games!

    Joined:
    Jul 11, 2013
    Messages:
    139
    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;
    }
    
    --- Double Post Merged, Dec 30, 2016, Original Post Date: Dec 30, 2016 ---
    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.
     
    HunterZ likes this.
  13. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    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: Dec 30, 2016
  14. alxm

    alxm Still making GP2X games!

    Joined:
    Jul 11, 2013
    Messages:
    139
    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.
     
  15. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    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
     
  16. HunterZ

    HunterZ Member

    Joined:
    Feb 27, 2011
    Messages:
    150
    Location:
    Seattle
    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?

    [​IMG]
    --- Double Post Merged, Jan 21, 2017, Original Post Date: Jan 21, 2017 ---
    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?
     
  17. hmn

    hmn Member

    Joined:
    Mar 8, 2010
    Messages:
    192
    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.

    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: May 30, 2017

Share This Page

Loading...