A Slightly More Complete Toolchain+Libs For Linux Devs ..


torpor

hack hack hack, the little machines fight back
Joined
Oct 21, 2005
Messages
2,475
Location
vienna, austria
Website
w1xer.at
So I spent some time last night building a fresh set of libs for Wiz development, based on Orkies script for building the libs (which didn't work too well until I fixed it). In case there are others who 'just want to get started with a toolchain and libs and don't want to fuss', I'm going to make this available for a little while, until I work out how to get my fixes of Orkies script into a form that can be used by anyone who wants to build these libs for themselves. Orkie's script is very useful, but the version on the Wiz dev wiki is buggy - I've fixed these bugs and will update the details a bit later on. This, here, is a binary release for you if you just want to get started with some libs.

This is the URL to the tarball containing both the TOOLCHAIN and my newly compiled libs for Wiz:

http://w1xer.de/toolchain-arm-openwiz-linux-gnu.tar.gz

Unzip this to /toolchain, then make the symlink
from /opt/openwiz/toolchain -> /toolchain. Like this:

# cd /
# tar xvfz /path/to/toolchain-arm-openwiz-linux-gnu.tar.gz
.. extracts to /toolchain ..
# mkdir -p /opt/openwiz [if needed]
# ln -s /toolchain /opt/openwiz/toolchain

The symlink is necessary because of the internal linker files having the
paths hard-coded .. Hope this makes sense to you.

You can see all the libs that are included
in /opt/openwiz/toolchain/arm-openwiz-linux-gnu/lib .. should look
something like this:


Code:
> gcc                             libfreetype.so.6       libmad.a                  libogg.so.0.5.3            libSDL.la                  libunicodefont.so
> imlib2                          libfreetype.so.6.3.18  libmad.la                 libpanel.a                 libSDLmain.a               libunicodefont.so.1.0.1
> libarm-openwiz-linux-gnu-sim.a  libgif.a               libmad.so                 libpanel_g.a               libSDL_mixer-1.2.so.0      libvorbis.a
> libbz2.a                        libgif.la              libmad.so.0               libpng12.a                 libSDL_mixer-1.2.so.0.2.6  libvorbisenc.a
> libcharset.a                    libgif.so              libmad.so.0.2.1           libpng12.la                libSDL_mixer.a             libvorbisenc.la
> libcharset.la                   libgif.so.4            libmenu.a                 libpng12.so                libSDL_mixer.la            libvorbisenc.so
> libcharset.so                   libgif.so.4.1.6        libmenu_g.a               libpng12.so.0              libSDL_mixer.so            libvorbisenc.so.2
> libcharset.so.1                 libhistory.a           libmikmod.a               libpng12.so.0.33.0         libSDL.so                  libvorbisenc.so.2.0.3
> libcharset.so.1.0.0             libhistory.so          libmikmod.la              libpng.a                   libSDL_svg-1.1.so.8        libvorbisfile.a
> libexpat.a                      libhistory.so.5        libmikmod.so              libpng.la                  libSDL_svg-1.1.so.8.0.1    libvorbisfile.la
> libexpat.la                     libhistory.so.5.2      libmikmod.so.2            libpng.so                  libSDL_svg.a               libvorbisfile.so
> libexpat.so                     libiberty.a            libmikmod.so.2.0.4        libpng.so.3                libSDL_svg.la              libvorbisfile.so.3
> libexpat.so.1                   libiconv.a             libmpcdec.a               libpng.so.3.33.0           libSDL_svg.so              libvorbisfile.so.3.2.0
> libexpat.so.1.5.2               libiconv.la            libmpcdec.la              libreadline.a              libSDL_ttf-2.0.so.0        libvorbisidec.a
> libfaad.a                       libiconv.so            libmpcdec.so              libreadline.so             libSDL_ttf-2.0.so.0.6.3    libvorbisidec.la
> libfaad.la                      libiconv.so.2          libmpcdec.so.5            libreadline.so.5           libSDL_ttf.a               libvorbisidec.so
> libfaad.so                      libiconv.so.2.4.0      libmpcdec.so.5.0.2        libreadline.so.5.2         libSDL_ttf.la              libvorbisidec.so.1
> libfaad.so.0                    libid3tag.a            libmpeg2.a                libSDL-1.2.so.0            libSDL_ttf.so              libvorbisidec.so.1.0.2
> libfaad.so.0.0.0                libid3tag.la           libmpeg2convert.a         libSDL-1.2.so.0.11.2       libtiff.a                  libvorbis.la
> libFLAC.a                       libid3tag.so           libmpeg2convert.la        libSDL.a                   libtiff.la                 libvorbis.so
> libFLAC++.a                     libid3tag.so.0         libmpeg2convert.so        libSDL_gfx.a               libtiff.so                 libvorbis.so.0
> libFLAC.la                      libid3tag.so.0.3.0     libmpeg2convert.so.0      libSDL_gfx.la              libtiff.so.3               libvorbis.so.0.4.0
> libFLAC++.la                    libImlib2.a            libmpeg2convert.so.0.0.0  libSDL_gfx.so              libtiff.so.3.8.2           libxml2.a
> libFLAC.so                      libImlib2.la           libmpeg2.la               libSDL_gfx.so.0            libtiffxx.a                libxml2.la
> libFLAC++.so                    libImlib2.so           libmpeg2.so               libSDL_gfx.so.0.0.17       libtiffxx.la               libxml2.so
> libFLAC++.so.6                  libImlib2.so.1         libmpeg2.so.0             libSDL_image-1.2.so.0      libtiffxx.so               libxml2.so.2
> libFLAC++.so.6.2.0              libImlib2.so.1.4.2     libmpeg2.so.0.1.0         libSDL_image-1.2.so.0.1.6  libtiffxx.so.3             libxml2.so.2.7.2
> libFLAC.so.8                    libjpeg.a              libncurses.a              libSDL_image.a             libtiffxx.so.3.8.2         libz.a
> libFLAC.so.8.2.0                libjpeg.la             libncurses++.a            libSDL_image.la            libungif.a                 libz.so
> libform.a                       libjpeg.so             libncurses_g.a            libSDL_image.so            libungif.la                libz.so.1
> libform_g.a                     libjpeg.so.62          libogg.a                  libSDL_inifile.a           libungif.so                libz.so.1.2.3
> libfreetype.a                   libjpeg.so.62.0.0      libogg.la                 libSDL_inifile.so          libungif.so.4              pkgconfig
> libfreetype.la                  libjpeg.so.7           libogg.so                 libSDL_inifile.so.1        libungif.so.4.1.6          preloadable_libiconv.so
> libfreetype.so                  libjpeg.so.7.0.0       libogg.so.0               libSDL_inifile.so.1.0.0    libunicodefont.a           xml2Conf.sh

NOTE: Orkie's script was somewhat borked on the following issues, which I fixed:

- Tried to configure SDL with pulseaudio support. Added --disable-pulseaudio to the SDL config script
- Couldn't find libjpeg-6b.. I updated the Makefile for libjpeg with a new URL for the library
- libtool for libjpeg was disastrous.. had all sorts of paths for important things like the ar-chiver and ld going to weird hard-coded locations .. this is now fixed (btw, /opt/openwiz/toolchain is *fixed as a path* in this tarball).

Another thing to note: name-collision with the OpenWIZ radio project. We should maybe change this at some point, because this will be bound to cause confusion, Bruces.

Good luck, let me know how it goes! I'll follow this thread, and also if you have other questions, in the evenings (Vienna, Europe time) I'll be lurking in #wizdev. I'm really on a mission to make Wiz development tools a little more palatable, and we want to get the GLES thing happening in a way that makes sense with this toolchain too, so I'll be watching that progress with hungry eyes. No pooftas!
 
I just searched for "libjpeg-6b.tar.gz" and used one of the URL's from this list:

http://www.filewatcher.com/m/libjpeg-6b.tar.gz.870723.0.0.html

I think one of the .jp domains .. worked fine and built fine too ..
 
torpor have you changes anything with the compiler itself, or is this all lib changes (which i reads like)
Feel free to update the toolchain in the archive if you think this improves on it. Or if the compiler is the same maybe just create a new archive with the dev libs.
 
Pickle - this is just a single tarball for newcomers, which includes your toolchain + development libs. I guess I should make it clear that not much happened on the toolchain side, though I think I will make a few modifications to the toolchain in a day or so to make it easier to relocate, and to integrate things a bit better. The reason I included the toolchain with the libs is that Orkie's build script installs things in the toolchain tree, and I wanted to be sure to reduce the hassle of newcomers in setting things up. Maybe you want to think about making a "toolchain+libs" release alongside the 'plain old toolchain' package, for those that want it - either just get the toolchain minus libs, or toolchain + libs. IMHO, a toolchain-only package is only useful for the hardcore guys who won't be using other public libs .. but for the most part, I think a lot of new Wiz hackers might appreciate just being able to unpack it and have everything they need to do a basic port without too much filesystem administration.

Anyway, this will be moot in a little while (plan on working on it more tomorrow), when I submit my fixes to Orkies libs build script so that it can be integrated. I just wanted to have a 'one tarball gets you what you need' available so that the interested folks can begin to build apps without too much setup fuss.

Another thing to add: if anyone wants to volunteer to write some sample apps for inclusion in the package, this is definitely needed. I figure if there was a single tarball with toolchain+libs+samples, this will make it a lot more palatable for new Linux hackers who want to target the Wiz to get started right away without having to collect too much from various places. One thing that frustrates me about this dev scene is that all the elite guys who make progress don't really present it well for newcomers .. having to go to glquake to get the NanoGL/libopengles packages is a bit .. well .. lame. Sorry. I just think there has to be a better administration of these items so that we all get a chance to make nice apps ..
 
torpor said:
Pickle - this is just a single tarball for newcomers, which includes your toolchain + development libs. I guess I should make it clear that not much happened on the toolchain side, though I think I will make a few modifications to the toolchain in a day or so to make it easier to relocate, and to integrate things a bit better. The reason I included the toolchain with the libs is that Orkie's build script installs things in the toolchain tree, and I wanted to be sure to reduce the hassle of newcomers in setting things up. Maybe you want to think about making a "toolchain+libs" release alongside the 'plain old toolchain' package, for those that want it - either just get the toolchain minus libs, or toolchain + libs. IMHO, a toolchain-only package is only useful for the hardcore guys who won't be using other public libs .. but for the most part, I think a lot of new Wiz hackers might appreciate just being able to unpack it and have everything they need to do a basic port without too much filesystem administration.

Anyway, this will be moot in a little while (plan on working on it more tomorrow), when I submit my fixes to Orkies libs build script so that it can be integrated. I just wanted to have a 'one tarball gets you what you need' available so that the interested folks can begin to build apps without too much setup fuss.

Another thing to add: if anyone wants to volunteer to write some sample apps for inclusion in the package, this is definitely needed. I figure if there was a single tarball with toolchain+libs+samples, this will make it a lot more palatable for new Linux hackers who want to target the Wiz to get started right away without having to collect too much from various places. One thing that frustrates me about this dev scene is that all the elite guys who make progress don't really present it well for newcomers .. having to go to glquake to get the NanoGL/libopengles packages is a bit .. well .. lame. Sorry. I just think there has to be a better administration of these items so that we all get a chance to make nice apps ..

Im perfectly fine with replacing the archive with the toolchain+libs. So please update it (it might become bad if theres 2 versions being used)

Cut me some slack on the glquake, the opengles support at the moment is very unstable. I havnt even gotten glquake to work on my wiz yet, i could barely call it progress. I dont know which opengles lib is the latest. I know your asking for a kit specific to opengles, but I just dont think its ready to dp that. GPH are still working on a new version and who knows it might change everything. My purpose was to release the source rather than hoard it. I did attempt to give some details on what was needed.
 
Last edited by a moderator:
Im perfectly fine with replacing the archive with the toolchain+libs. So please update it (it might become bad if theres 2 versions being used)

I'll be doing some more work on this in the evening today, and will try to clean it up so that it makes a bit more sense, administratively. I definitely need to get into the Wiki side of things and sync it up with the reality of the toolchains now that we're building things.

Plus, I need to have a bit more of a hack session on using the libs in case there are some lingering issues with using them for development. Right now that session is bound to be a bit of a painful one due to lack of console access, but I'll get in there and do some more qualitative assessment of the toolchain/libs in order to smooth it out.

Cut me some slack on the glquake, the opengles support at the moment is very unstable. I havnt even gotten glquake to work on my wiz yet, i could barely call it progress. I dont know which opengles lib is the latest. I know your asking for a kit specific to opengles, but I just dont think its ready to dp that. GPH are still working on a new version and who knows it might change everything. My purpose was to release the source rather than hoard it. I did attempt to give some details on what was needed.

Consider the slack sliced and flapping around in the wild, wild winds! ;) I'm aware that there are some changes on the horizon; the progress you've made so far is pretty impressive indeed. I hope we soon get to the point where toolchain+libs is all you need in order to start making a nice, clean, fast, 3D-using (if needed), efficient bit of code. After all, I'd actually prefer to be playing original 3D games on a nice little new console from fresh developers, rather than hacking around the edges of the toolchain. Just hope that happens.
 
torpor said:
Consider the slack sliced and flapping around in the wild, wild winds! ;) I'm aware that there are some changes on the horizon; the progress you've made so far is pretty impressive indeed. I hope we soon get to the point where toolchain+libs is all you need in order to start making a nice, clean, fast, 3D-using (if needed), efficient bit of code. After all, I'd actually prefer to be playing original 3D games on a nice little new console from fresh developers, rather than hacking around the edges of the toolchain. Just hope that happens.
I agree, but we just need to wait until something solid comes from GPH, i dont see any reason to set something up that cant be linked to directly. Ive heard from them direct a much better version is on the way.
 
Last edited by a moderator:
your

Code:
# ln -s /toolchain /opt/openwiz/toolchain

is what makes me worry about this solution, still looks like the best all-in-one solution there currently is (for linux). :/
 
Most people should just install it to /opt directly, that is after all what /opt is for ;).
 
Yeah I'm not keen on that link either, no_skill .. its possible we don't need it, but I haven't had the time to grok the tree and see if anything uses that path.

I've sort of put my Wiz hacking on hold until I can get a serial cable made, probably get this done in the next two days or so .. then I'll get back to it and add OpenGLES to the libs, with some samples (got it already done for Pandora/Beagleboard) ..
 
Never been a fan of opt, myself, nor of anything that puts things in root un-necessarily. Much better: /usr/local.
 
Sphinxter said:
No /opt in UNIX, that started with Solaris..
Aha, but this is for LSB Linux distributions, not UNIX!
 
Last edited by a moderator:
Orkie said:
Sphinxter said:
No /opt in UNIX, that started with Solaris..
Aha, but this is for LSB Linux distributions, not UNIX!

Does it really matter? A folder is just a folder. I actually put my toolchains on a shared folder so I can access them from any pc. As long as you know how to use a prefix it doesnt matter where you stick it.
 
Last edited by a moderator:
My /opt is a link to /usr/local/opt. Only matters if you build old school with separate file systems as in
Code:
   Filesystem           1K-blocks      Used Available Use% Mounted on
   /dev/sda3               501244    229424    271820  46% /
   udev                     10240       172     10068   2% /dev
   /dev/sda5              7998128   1801272   6196856  23% /var
   /dev/sda6              3997944     11636   3986308   1% /tmp
   /dev/sda7             15998500   5760012  10238488  37% /home
   /dev/sda8             15998500  11443740   4554760  72% /usr
   /dev/sda9            103472280  25448024  78024256  25% /usr/local
   shm                    3066372         0   3066372   0% /dev/shm
Makes it easier to archive.
 
Hi,

I'm trying to port Nethack with this toolchain. It compiles successfully, but when I try to run it, I get a eternal Loading screen. I tried to run it from Termula2x and a see these errors:

With dynamic compilation:
./nethack_dyn.gpe: /lib/libpng12.so.0: no version information available (required by ./nethack_dyn.gpe)

With static compilation:
FATAL: kernel too old
Segmentation fault


Also, as a test, id tried to compile last Mame4all from Franxis (dynamic compilation). I got this error when I run it:
./mame_yo.gpe: /lib/libgcc_s.so.1: Version 'GCC_4.2.0' not found (required by ./mame_yo.gpe)

I'm using Wiz's firmware 1.1.0. How can I solve this? Thank you.
 
WinterN said:
Hi,

I'm trying to port Nethack with this toolchain. It compiles successfully, but when I try to run it, I get a eternal Loading screen. I tried to run it from Termula2x and a see these errors:

With dynamic compilation:
./nethack_dyn.gpe: /lib/libpng12.so.0: no version information available (required by ./nethack_dyn.gpe)

With static compilation:
FATAL: kernel too old
Segmentation fault


Also, as a test, id tried to compile last Mame4all from Franxis (dynamic compilation). I got this error when I run it:
./mame_yo.gpe: /lib/libgcc_s.so.1: Version 'GCC_4.2.0' not found (required by ./mame_yo.gpe)

I'm using Wiz's firmware 1.1.0. How can I solve this? Thank you.

static compiling hasnt worked at all for me i get similiar errors.
I dont think that error message for dynamic version is the real problem, im pretty sure ive seen that but programs still run. There might be a different issue.
Your mame build needs that gcc lib next to the binary, ive had to include that with some things ive done.
 
Last edited by a moderator:
I think the problem is that the toolchain comes with libs, and the Open2X script comes with libs, and you have to be careful not to mix them up.

Check out the Makefile in this thread: Basic SDL Example .. to get a proper Makefile configuration that should work with the libs being included in the proper order.
 
Last edited by a moderator:
Back
Top