My first attempt at a FAQ for building tardists for nekoware. It's grossly incomplete, contains arrogant remarks, smells like dogpoo and is probably not very accurate. Please comment on this FAQ in the regular thread "Nekoware tardists build FAQ" started by O2ric and post suggestions! I'll be doing additions on this document in a hopeful steady rate. Hence my posting today, otherwise this will never get finished
The Nekoware Tardist Build FAQ
collected by Frank Everdij aka dexter1 29 oct 2004
Intro
This is supposed to be a guide about making nekoware tardist packages to be enjoyed on SGI IRIX machines, aka those funny colored machines with a cube logo up front which costed a small car back in the days...
Rules
First of all we need to define some rules on what packages we intend to be released as nekoware and on what platforms they should run. We aim at opensource software, GNU GPL or BSD license or other free/non-commercial license, usually developed on linux x86 machines. Because these opensource software were mainly developed on x86 architecture, this poses some constraints on the target machine. It should have reasonably fast IO, fast integer performance and for building code it should run a recent MIPSPro compiler which can squeeze as much performance from code as it can.
As target SGI machines, we have chosen the following:
1) MIPS IV instruction set, meaning all machines with R5000 processors and up, which include: R5K Indy, R8K Indigo2, R10K Indigo2 Impact, R8K and R10K Challenge, R8K and R10K Onyx1, all O2, all Octane, all Onyx2, all Origin, Tezro, Fuel.
2) Minimum IRIX to run is 6.5.21m. On supportfolio you can get hold of 6.5.22m overlays, but take care to install Patch 5086 first if you plan to upgrade. People running less than 6.5.21 can use nekoware, but need some runtime modifications with RLD_LIST becuae of missing symbols, most notably strlcpy and strlcat. Ugly, but it works. Also take care to install the latest patches for the OS.
3) MIPSPro 7.4.x is the preferred compiler choice. Mipspro 7.3.1.3m is also pretty good and for some apps it's even better than the 7.4.x series. We discourage the use of gcc 3.x, though sometimes it is the only choice. Unsure is, if compiling c++ code with g++ will play with MIPSPro compiled code, because of name mangling issues.
4) IRIX 6.5.22m is our preferred build platform OS. This IRIX is the end of the line for a lot of older machines, has mp3 support, UDF, IPV6, NTP, in short a nice OS, is fairly recent, and if reasonably patched, quite stable.
Port/Compile
Porting opensource on IRIX platform is sometimes not an easy task. To name a few major problems:
1) Endianness. IRIX is big-endian, meaning that word/multiword storage starts with the most significant byte first. x86 PC's are little-endian. So you can have situations where you need to swap bytes around before or after processing variables in routines.
2) ASM. Forget it. Optimised x86 assembly code will never run on MIPS. Ditch the software and find a C/C++ equivalent.
3) GCC-isms. A name bundling a variety of hacks (void pointer arithmetics), oddball coding (namespace clashes), wrong standards (C++ iostreambuf return pointer), hard-coded Makefiles (the worst) and botched/ignorant ./configure scripts (even worse than worst). Sometimes switching to c99 instead of cc fixes a lot of gcc-isms. In the code atleast
4) Different device handling, most notably parallel port programming and audio. No joysticks
no USB (except your mouse on the Tezro)
5) Performance/Speed. MIPS being a floating point killer has trouble with integer code. Most opensource code do not take this into consideration, so optimisations are needed to crank up the code to make it run at useable speeds on your IRIX box.
Minor problems like misplaced or missing headers can usually be fixed by a bit of searching and #ifdef's wrapping. __sgi is a nice symbol to use for that, though most ./configure scripts can determine that you're running MIPS and set defines accordingly. Also defines which include BSD in the name are sometimes a good idea, since IRIX is a BSD style Unix flavor.
Selecting a good environment is necessary to get a proper build. A good starting point is:
CC is the basic C compiler environment name, which usually gets picked up by ./configure scripts. sometimes one may have to substitute it with:
CXX is the C++ compiler environment name. It should be CC or g++ if the code is too messy to compile with MIPSPro.
CFLAGS and CXXFLAGS should be small and neat. -O3 gives you the best optimisation for a first compile attempt. -mips4 selects MIPS IV instruction set optimisations. -n32 select 32bit addressing, so pointers should not exceed 2 Gb, which rarely happens with opensource programs.
/usr/nekoware/include and /usr/nekoware/lib should be good include and lib paths for porting an app to nekoware. If you need more libs to port an app, it may be an idea to first build it into /usr/local, so you can test the code before doing a proper nekoware build.
Other less used environment variables which can be picked up by ./configure are
Packaging
Try to start ports with the necessary prerequisites installed, preferably nekoware packages if you plan to make a nekoware tardist. Although nekoware doesn't bite with freeware, some ./configure scripts can get confused with two similar named libraries in different locations. Imagine a package including /usr/freeware/include/jpeg.h and linking with /usr/nekoware/lib/libjpeg.so...
So it's best to dedicate a machine for that.
I compile most opensource stuff for nekoware in /usr/local/src/<programname-version>
For building packages i have made a directory /usr/local/src/build and in there i make a directory <programname> where i store the following; Lets give and example for the program called "program" In /usr/local/src/build/program :
1) neko_program.idb <- swpkg/gendist package list of files and actions
2) neko_program.spec <- specification file of subsystems, versions and dependencies
3) neko_program.txt <- text file with specifications on the build proces, program version, used environment variables, ./configure options, dependencies needed, background info, sometimes test results or performance numbers.
4) program-1.2.3.tar.gz or program-1.2.3.tar.bz2 <- original program tarball. Always leave the tarball intact, because the source code and copyright notice should remain available.
5) neko_program-1.2.3_irix.patch <- patch file to patch the source. should be a cat of diff -u output applied inside the source path /usr/local/src/program-1.2.3 so it should be appliable with "patch -p0 < neko_program-1.2.3_irix.patch"
6) clean.txt and program.txt <- These are ls -lR outputs of /usr/nekoware done as root, before and after a "make install" so i know what files have been added/deleted by doing a diff or xdiff of these two files.
5) and 6) are more or less my choices but 1) through 4) are mandatory files and should be included in the nekoware tardist build so people can recreate the tardist if needed.
More to come after my beauty sleep
The Nekoware Tardist Build FAQ
collected by Frank Everdij aka dexter1 29 oct 2004
Intro
This is supposed to be a guide about making nekoware tardist packages to be enjoyed on SGI IRIX machines, aka those funny colored machines with a cube logo up front which costed a small car back in the days...
Rules
First of all we need to define some rules on what packages we intend to be released as nekoware and on what platforms they should run. We aim at opensource software, GNU GPL or BSD license or other free/non-commercial license, usually developed on linux x86 machines. Because these opensource software were mainly developed on x86 architecture, this poses some constraints on the target machine. It should have reasonably fast IO, fast integer performance and for building code it should run a recent MIPSPro compiler which can squeeze as much performance from code as it can.
As target SGI machines, we have chosen the following:
1) MIPS IV instruction set, meaning all machines with R5000 processors and up, which include: R5K Indy, R8K Indigo2, R10K Indigo2 Impact, R8K and R10K Challenge, R8K and R10K Onyx1, all O2, all Octane, all Onyx2, all Origin, Tezro, Fuel.
2) Minimum IRIX to run is 6.5.21m. On supportfolio you can get hold of 6.5.22m overlays, but take care to install Patch 5086 first if you plan to upgrade. People running less than 6.5.21 can use nekoware, but need some runtime modifications with RLD_LIST becuae of missing symbols, most notably strlcpy and strlcat. Ugly, but it works. Also take care to install the latest patches for the OS.
3) MIPSPro 7.4.x is the preferred compiler choice. Mipspro 7.3.1.3m is also pretty good and for some apps it's even better than the 7.4.x series. We discourage the use of gcc 3.x, though sometimes it is the only choice. Unsure is, if compiling c++ code with g++ will play with MIPSPro compiled code, because of name mangling issues.
4) IRIX 6.5.22m is our preferred build platform OS. This IRIX is the end of the line for a lot of older machines, has mp3 support, UDF, IPV6, NTP, in short a nice OS, is fairly recent, and if reasonably patched, quite stable.
Port/Compile
Porting opensource on IRIX platform is sometimes not an easy task. To name a few major problems:
1) Endianness. IRIX is big-endian, meaning that word/multiword storage starts with the most significant byte first. x86 PC's are little-endian. So you can have situations where you need to swap bytes around before or after processing variables in routines.
2) ASM. Forget it. Optimised x86 assembly code will never run on MIPS. Ditch the software and find a C/C++ equivalent.
3) GCC-isms. A name bundling a variety of hacks (void pointer arithmetics), oddball coding (namespace clashes), wrong standards (C++ iostreambuf return pointer), hard-coded Makefiles (the worst) and botched/ignorant ./configure scripts (even worse than worst). Sometimes switching to c99 instead of cc fixes a lot of gcc-isms. In the code atleast
4) Different device handling, most notably parallel port programming and audio. No joysticks
no USB (except your mouse on the Tezro)
5) Performance/Speed. MIPS being a floating point killer has trouble with integer code. Most opensource code do not take this into consideration, so optimisations are needed to crank up the code to make it run at useable speeds on your IRIX box.
Minor problems like misplaced or missing headers can usually be fixed by a bit of searching and #ifdef's wrapping. __sgi is a nice symbol to use for that, though most ./configure scripts can determine that you're running MIPS and set defines accordingly. Also defines which include BSD in the name are sometimes a good idea, since IRIX is a BSD style Unix flavor.
Selecting a good environment is necessary to get a proper build. A good starting point is:
Code: Select all
setenv CC cc
setenv CXX CC
setenv CFLAGS '-O3 -mips4 -n32'
setenv CXXFLAGS '-O3 -mips4 -n32'
setenv CPPFLAGS '-I/usr/nekoware/include'
setenv LDFLAGS '-L/usr/nekoware/lib'
CC is the basic C compiler environment name, which usually gets picked up by ./configure scripts. sometimes one may have to substitute it with:
Code: Select all
setenv CC c99 (only for mipspro 7.4.x) or
setenv CC c89 to select a more gcc-like parsing and compiling behaviour.
CXX is the C++ compiler environment name. It should be CC or g++ if the code is too messy to compile with MIPSPro.
CFLAGS and CXXFLAGS should be small and neat. -O3 gives you the best optimisation for a first compile attempt. -mips4 selects MIPS IV instruction set optimisations. -n32 select 32bit addressing, so pointers should not exceed 2 Gb, which rarely happens with opensource programs.
/usr/nekoware/include and /usr/nekoware/lib should be good include and lib paths for porting an app to nekoware. If you need more libs to port an app, it may be an idea to first build it into /usr/local, so you can test the code before doing a proper nekoware build.
Other less used environment variables which can be picked up by ./configure are
Code: Select all
setenv PERL /usr/nekoware/bin/perl
setenv GNUMAKE /usr/nekoware/bin/gmake
setenv SED /usr/nekoware/bin/sed
Packaging
Try to start ports with the necessary prerequisites installed, preferably nekoware packages if you plan to make a nekoware tardist. Although nekoware doesn't bite with freeware, some ./configure scripts can get confused with two similar named libraries in different locations. Imagine a package including /usr/freeware/include/jpeg.h and linking with /usr/nekoware/lib/libjpeg.so...
So it's best to dedicate a machine for that.
I compile most opensource stuff for nekoware in /usr/local/src/<programname-version>
For building packages i have made a directory /usr/local/src/build and in there i make a directory <programname> where i store the following; Lets give and example for the program called "program" In /usr/local/src/build/program :
1) neko_program.idb <- swpkg/gendist package list of files and actions
2) neko_program.spec <- specification file of subsystems, versions and dependencies
3) neko_program.txt <- text file with specifications on the build proces, program version, used environment variables, ./configure options, dependencies needed, background info, sometimes test results or performance numbers.
4) program-1.2.3.tar.gz or program-1.2.3.tar.bz2 <- original program tarball. Always leave the tarball intact, because the source code and copyright notice should remain available.
5) neko_program-1.2.3_irix.patch <- patch file to patch the source. should be a cat of diff -u output applied inside the source path /usr/local/src/program-1.2.3 so it should be appliable with "patch -p0 < neko_program-1.2.3_irix.patch"
6) clean.txt and program.txt <- These are ls -lR outputs of /usr/nekoware done as root, before and after a "make install" so i know what files have been added/deleted by doing a diff or xdiff of these two files.
5) and 6) are more or less my choices but 1) through 4) are mandatory files and should be included in the nekoware tardist build so people can recreate the tardist if needed.
More to come after my beauty sleep
