Download either LOANI-0.6.zip or LOANI-0.6.tar.gz, extract it, execute
loani.sh --buildTools as your normal user to have OSDL, Ceylan and all their prerequisites, including the whole build chain, automatically and safely downloaded, extracted, configured, compiled and built together for you, when targeting the PC.
If cross-compiling for the Nintendo DS, just add:
--nds. If wanting only the Orge server, just use the
--onlyOrgeTools option. That's all!
If wanting to build the OSDL toolchain for Windows, just refer to this document instead.
This is the manual page for LOANI version 0.6.
LOANI stands for Lazy OSDL's Automatic Net Installer. Its purpose is to simplify as much as possible the installation of OSDL and its prerequisites on supported platforms, notably Windows and most UNIX platforms, including GNU/Linux.
Installed developments may include, depending on the choice of the LOANI user:
We really understand there are much more enjoyable activities than to painfully install an intricate list of in some cases cyclic dependencies in order to have one's library working. That's why it ought to be automated.
Some operating systems, such as GNU/Linux with for example the Debian or Gentoo distributions, automate software installations with a package system. However it does not discard the need of tools like LOANI, as we must compile with dedicated options specific versions of helper libraries. Most often package managers do not let easily choose the options sets and/or offer too old versions and/or patch them inaccurately. For example, SDL_image did not build with gcc higher than 3.4, and needs to be configured with JPEG, PNG support, but not TIFF one. LOANI takes in charge that task automatically and without complaining.
That's why we imagined LOANI: the simplest shell script (on the user side) that performs everything on your behalf and cooks you a brand new OSDL-compliant environment from scratch, with almost no effort but the typing of a simple line:
Its main targeted audience is the developer community. For end users, a set of platform-specific binaries will be available in a vague future.
Even though all the tools used are available on the most common platforms, OSDL and, notably, Ceylan, are still to be ported so that they can be executed reliably elsewhere than on Windows or GNU/Linux. Our next targets will be the various Mac OS X flavours, so that most gamers can be reached.
LOANI is released under the GNU GPL licence.
LOANI has been thoroughly tested first on GNU/Linux platforms, with various hardware and distributions [More info]. Even if some bugs may appear (on error, please see LOANI troubleshooting), we believe most of LOANI's users should experience a good behaviour of this tool.
The other main targeted platforms are the Windows ones (98/Me/XP/Vista), using Cygwin as host environment, and Visual Express Edition (at least 2005) as compilation toolchain. Both are totally free. As on Windows this developer environment may be a bit difficult to settle down, we wrote a small step-by-step guide to have one's build environment working. Windows users must apply it first before running LOANI.
For other platforms, some adaptations may have to be performed. A general rule of thumb is to use as much as possible GNU tools, in order to be on the safe side. We will welcome reports of tests or, even better, patches to have LOANI working on other platforms.
One of course should have a working Internet connection in order to retrieve the target packages, if needed: one could indeed pre-fetch archives thanks to any available way (ex: a CD or an USB key) and put them in LOANI's cache repository, to avoid any subsequent download. Note also that we try to maintain a last-resort up-to-date FTP cache, to overcome outages of the respective official download locations (LOANI will then make automatically use of it).
All of them should already be available on most UNIX-like systems:
For Windows-based systems, selecting most tools in the Cygwin set-up should be enough.
For Debian-based systems, this command should help:
sudo apt-get update && apt-get install coreutils gawk tar gzip bzip2 wget make cmake gcc g++ flex subversion autoconf automake x11proto-xext-dev libjpeg-dev mesa-common-dev libglu1-mesa-dev
For RPM-based systems like OpenSuse, this command should help:
sudo yast --update && yast -i coreutils gawk tar gzip bzip2 wget make cmake gcc gcc-c++ flex subversion autoconf automake xorg-x11-proto-devel libjpeg-devel Mesa Mesa-devel
Please note that these prerequisites are LOANI's ones, which are a subset of full OSDL's ones. The complementary tools should be retrieved, installed and used automatically by LOANI, if requested (ex: the C++ compiler).
LOANI is a user-friendly tool for OSDL, which can let you choose one or more tool selections and will automatically retrieve, configure, compile, install and link together the corresponding tools in their relevant versions.
All the managed tools are free software (free of charge and open source).
Only basic settings are described here: should the Nintendo DS environment be selected (thanks to the
--nds command-line option), the software set would differ drastically. The toolchain would then be based on devkitARM, dlditool, libnds, PA_lib, libfat, dswifi, etc., although it would lead finally to Ceylan and OSDL as well (after quite different paths). See our tool section in our DS homebrew guide for more details.
See our Orge section for specific details about the Orge support.
This tool selection is mandatory for OSDL's functioning, therefore no specific option has to be passed to LOANI to have it taken into account. Following prerequisites are managed, with dependencies shown (LOANI manages all the dependency tree, i.e. the prerequisites of prerequisites and so on):
Following first-order dependencies are selected:
rpathset. Otherwise this would prevent distributing prebuilt OSDL libraries (see this link for further information)
OSDL is our generic multimedia library built on top of these prerequisites.
Ceylan and OSDL can be both retrieved thanks to a source release archive or thanks to SVN. In the first case, a compressed archive is downloaded by LOANI (as it does for other tools), whereas with SVN the source tree is retrieved, according to the chosen version, developer or end user.
Thanks to the
--sourceforge <user name> option, our project developers can retrieve a fresh (coming from the always up-to-date developer SVN server) check-out version of Ceylan and OSDL, in order to have painlessly a developer-ready install, since SVN information will be managed and retrieved too. Note that this option implies the
--currentSVN option, which means that the cutting edge sources are wanted, even though the build tree is often broken during development.
End-users that prefer SVN should use
--useSVN instead of the two previous options. The retrieved sources will then be the result of a SVN export made from the anonymous SVN server, and no SVN meta-data will be managed. Unless the
--currentSVN option is specifically set, retrieved files for Ceylan and OSDL correspond to their respective last stable versions, as determined by SVN tags (ex:
STABLE_20040906). If the
--currentSVN option is set, then the latest version of each file is used. This is usually unsafe during development.
Note that, as LOANI uses the SVN client provided by Cygwin, a checkout may report a success whereas it actually failed, if it resulted into too long paths. One should use TortoiseSVN after this checkout and perform an update, just to be sure all files are here.
More generally, one should avoid trying to perform any LOANI installation from a directory already too much nested in the filesystem tree (ex: in a deep directory below
My Documents), as some Windows tools may fail in that case.
These build tools or counterparts of them (other C++ compilers, same tools with different versions) might already be readily available on user's system. If not, or if tool versions do not match the required ones, select this tool section, thanks to the
--buildTools LOANI option.
Installing by oneself these build tools is quite often needed, since for example gcc often breaks downward binary compatibility for C++ base libraries: we often need a very precise version of
libstdc++. As we already chose for you the latest gcc version able to build all OSDL prerequisites, relying on LOANI to install gcc and other build tools as well is a safe bet.
Note that using that option assumes that a working C compiler is already locally available on your computer, since the build tools will be themselves built from sources. However all usual GNU/Linux platforms offer that.
Moreover, building gcc now requires GMP and MPFR. One should thus ensure these packages are available beforehand. For example Ubuntu users should execute as root:
apt-get install libgmp3-dev libmpfr-dev before launching LOANI.
These tools are not strictly needed, but are helpful for developers and/or documentation maintainers, who ought to make use of them. You can request this tool selection thanks to the
--optionalTools LOANI option.
The technical environment used by server-side Orge is quite different from the Ceylan and OSDL C++ main code path. Thus if LOANI is requested to install Orge (ex:
./loani.sh --onlyOrgeTools --prefix /home/orge/software), instead of the C++ toolchain, the Erlang one will be installed and used afterwards.
Note that the development package for libcurses is needed to build Erlang. For example, on Debian and Ubuntu,
apt-get install libncurses5-dev should be executed before running LOANI.
Installation and packages are more precisely described in the Orge technical manual.
If one wants to select all the above managed tools (required, build and optional), simply use the
--allTools LOANI option. The user should end up with a total installation weighing approximately 300 megabytes, if stripped down with archive cache removed. Let's remember that gigabytes are cheap!
Speaking of build duration, the whole process (retrieving all the files from the net and building all) lasts less than 90 minutes in an otherwise idle average PC with a 128 kb broadband access.
LOANI has the ability to provide its user a developer-friendly UNIX environment. It consists on well configuring bash, some editors (nedit, vim) and some other defaults. To have one's environment updated and improved, add the
Please note that all pre-existing configuration files are kept in a copy suffixed by
.previous. One should therefore not loose any configuration information, since LOANI stops on error whenever there already exists a backup file in the way.
One should download either the LOANI-0.6.zip or LOANI-0.6.tar.gz archive.
Always as a normal user (using root is not recommended for the moment), after having downloaded it, one has to extract the archive, with
unzip LOANI-0.6.zip or
gunzip < LOANI-0.6.tar.gz | tar xvf - (note that
tar -xvzf LOANI-0.6.tar.gz should work with GNU-based tar). Change now to the extracted directory:
Then, to figure out the main options, one could use:
To benefit from our embedded tiny text wizard (answer the questions and everything should go fine):
Otherwise, most end-users may use directly:
whereas (registered) Ceylan/OSDL developers may use for example:
Many users wish everything to be installed in the current working directory, and therefore do not even have to set a specific prefix.
If ever errors occured (which might happen), one may take a look at
LOANI.log, a log file created in the directory from which LOANI was launched, or directly at the script itself,
loani.sh (this simple script is easy to understand and customise) and/or send us a notice to have LOANI improved.
There are often many problems coming from build tools:
libgcc_s.sobreaking existing builds)
For all these reasons and many others, the user build environment might not be able to behave correctly, preventing OSDL to be built. Therefore we added the
--buildTools option which takes totally care of it, on the user's behalf in order not to mess up in any case with system installation. The compiler, gcc, libtool and all other tools will be in this case automatically installed and used as they should, without interfering with existing configuration.
This option, which should be used in order to be in the safe side, can be specified that way:
Note that the
--allTools option implies the
Here is a sample of what should happen:
tester@testingHost LOANI-0.6 $ ./loani.sh --allTools < Welcome to Loani > This is the Lazy OSDL Automatic Net Installer, dedicated to the lazy and the fearless. Its purpose is to have OSDL and all its prerequisites installed with the minimum of time and effort. Some time is nevertheless needed, since some downloads may have to be performed, and the related build is CPU-intensive, so often a bit long. Therefore, even with a powerful computer and broadband access, some patience will be needed. Warning: No prefix specified and not run as root (which is recommended indeed): adding prefix /home/tester/LOANI-0.6/LOANI-installations. Retrieving all prerequisites, pipe-lining when possible. Target package list is <libtool SDL libjpeg zlib libpng SDL_image SDL_gfx freetype SDL_ttf libogg libvorbis SDL_mixer Ceylan OSDL>. Some tools already available (libtool SDL libjpeg zlib libpng SDL_image SDL_gfx freetype SDL_ttf libogg libvorbis SDL_mixer Agar PhysicsFS), others will be downloaded (Ceylan OSDL). Retrieving Ceylan from developer SVN with user name wondersye. ----> getting Ceylan from SVN with user name wondersye (check-out) <---- Ceylan retrieved [from SVN] Retrieving OSDL from developer SVN with user name wondersye. ----> getting OSDL from SVN with user name wondersye (check-out) <---- OSDL retrieved [from SVN] All prerequisites available. ----> libtool : extracting [OK] configuring [OK] building [OK] installing [OK] ----> SDL : extracting [OK] configuring [OK] building [OK] installing [OK] ----> libjpeg : extracting [OK] configuring [OK] building [OK] installing [OK] ----> libzlib : extracting [OK] configuring [OK] building [OK] installing [OK] ----> libPNG : extracting [OK] configuring [OK] building [OK] installing [OK] ----> SDL_image : extracting [OK] configuring [OK] building [OK] installing [OK] ----> SDL_gfx : extracting [OK] configuring [OK] building [OK] installing [OK] ----> freetype : extracting [OK] configuring [OK] building [OK] installing [OK] ----> SDL_ttf : extracting [OK] configuring [OK] building [OK] installing [OK] ----> libogg : extracting [OK] configuring [OK] building [OK] installing [OK] ----> libvorbis : extracting [OK] configuring [OK] building [OK] installing [OK] ----> SDL_mixer : extracting [OK] configuring [OK] building [OK] installing [OK] ----> Agar : extracting [OK] configuring [OK] building [OK] installing [OK] ----> PhysicsFS : extracting [OK] configuring [OK] building [OK] installing [OK] ----> Ceylan : extracting [OK] configuring [OK] building [OK] installing [OK] ----> OSDL : extracting [OK] configuring [OK] building [OK] installing [OK] Post-install cleaning of build trees. End of LOANI, started at 19:00:44, successfully ended at 19:20:15. You can now test the whole installation by executing /home/tester/LOANI-0.6/LOANI-installations/OSDL-0.5/share/OSDL-test/playTests.sh
On a side note, LOANI usually have to ask some more questions. The first is:
The authenticity of host 'osdl.svn.sourceforge.net (18.104.22.168)' can't be established. DSA key fingerprint is 02:ab:7c:aa:49:ed:0b:a8:50:13:10:c2:3e:92:0f:42. Are you sure you want to continue connecting (yes/no)?
yes to this one, it is just the SSH-powered SVN client wanting the user to acknowledge the connection to SourceForge's SVN server, whereas the user host never before had been connected to that server. That should not be a problem for anybody.
The other question is, for the registered OSDL users that chose the SVN developer access (
--sourceforge option) but did not set up authentication by SSH public key on Sourceforge'side (very few happen to use them), the following:
<your sourceforge user>@osdl.svn.sourceforge.net's password:
This question may be asked more than two times (at least one for Ceylan, and one for OSDL). It is due to SourceForge's SVN servers' hiccups, LOANI will try multiple times before aborting, in the case where there is an outage of SourceForge services. Each time, answer in an appropriate way and everything should work well.
loani.shand let it do its best alone
PROXY_CONFenvironment variable (bash example:
export PROXY_CONF='--proxy-user=<my user name> --proxy-passwd=<my password>')
LOANI-installations. If root tries running LOANI, he will be prompted to confirm, since this choice is not recommended
loani.sh --helpgives you detailed information
This is loani.sh, the famous Lazy OSDL Automatic Net Installer.
Usage: loani.sh [ -d | --debug ]
[ -s | --strict ]
[ -q | --quiet ]
[ -w | --wizard ]
[ -u | --useSVN ]
[ -c | --currentSVN ]
[ --sourceforge <user name> ]
[ --buildTools ]
[ --optionalTools ]
[ --OrgeTools ]
[ --onlyOrgeTools ]
[ --allTools ]
[ --nds ]
[ --setEnv ]
[ --fetchonly ]
[ --all ]
[ --prefix <a path> ]
[ --repository <a path> ]
[ --noLog ]
[ --noClean ]
[ -h | --help ]
-d or --debug : display debug information to screen
-s or --strict : be strict, stop on wrong md5 checksums or on unexpected tool locations
-q or --quiet : avoid being too verbose
-w or --wizard : enter wizard interactive mode, so that questions are asked to configure
-u or --useSVN : retrieve Ceylan and OSDL from SVN, instead of downloading pre-packaged source archives
-c or --currentSVN : retrieve current SVN for Ceylan and OSDL, instead of latest SVN tagged stable release (implies --useSVN)
--sourceforge <user name>: uses SourceForge developer access to retrieve projects from SVN (implies --currentSVN)
--buildTools : retrieve and install common build tools too (ex: gcc, binutils, gdb)
--optionalTools : retrieve and install optional tools too (ex: doxygen, dot, tidy)
--OrgeTools : retrieve and install all tools for Orge (ex: Erlang)
--onlyOrgeTools : retrieve and install all tools for Orge, and no other tool
--allTools : retrieve all tools (required, build, optional tools)
--nds : set mode for cross-compilation from GNU/Linux to Nintendo DS homebrew
--setEnv : set full developer environment (ex: bash, nedit configuration)
--fetchonly : only retrieve (download in cache) prerequisite, do not install them
--all : install all and set all
--prefix <a path> : install everything under <a path>
--repository <a path> : specify an alternate cache repository for downloads
--noLog : do not log installation results
--noClean : do not remove build trees after a successful installation
-h or --help : display this message
Recommended example (long but safe): loani.sh --allTools
There exist some hidden options, i.e. undocumented in the command line help, since seldom used:
--noSVN: do not retrieve Ceylan or OSDL from SVN, merely used for LOANI debugging (they will not be retrieved at all)
--onlyBuildTools: only build tools will be installed
--onlyOptionalTools: only optional tools will be installed
The most common mistakes that are made or errors that occur are listed here, alongside with their solution.
./loani.sh: /bin/bash: bad interpreter: Permission denied
/bin/bashis not a valid link, or it does not refer to an executable file, or you are on a partition whose
noexecattribute is set (use the
mountcommand to check, for example the
userfstab attribute implies it). Finally, check that the
loani.shscript was not corrupted by a transfer (for example, beware of Windows and CR/LF transformations, think to
dos2unixif you have a weird transfer client), and of course that the script is still executable.
"Error: XYZ archive not available through main server or known mirrors.
LOANI-repositoryif not specifically overridden, and to launch LOANI again.
The main culprit for that case seems to be Sourceforge's SVN which experiences some outages that lead to a never-ending check-out. A good workaround is to type
CTRL-C in the terminal from which LOANI is run, it will force a SVN reset which will result in another SVN attempt of LOANI which, in most cases, then succeeds.
Another frequent cause of problem is SVN needing the user to acknowledge interactively the use of Sourceforge certificate. Using
tail -f LOANI.log, one can see a message like:
Most simple work-around is to accept manually the certificate from a terminal with
svn co https://osdl.svn.sourceforge.net:/svnroot/ceylan for example, to stop it once the certificate has been accepted, to remove any downloaded directory, and then to launch LOANI again.
Otherwise the issue and its solution are mostly the same as for the previous case. Typically, LOANI succeeded in downloading most packages, but, for one or more, does not progress any more. Using again
tail -f LOANI.log, you may see LOANI regularly waiting for the lacking packages, and inspecting the various
wget-log.* shows some messages like
failed: Connection timed out.
This may happen if a download mirror is experiencing some kind of internal errors. Despite the fact that mirrors used by LOANI are selected among the major and most available ones, some outages already occured. Some temporary network failures may happen too. Most of the time LOANI overcomes these problems and defaults to the next available mirror: just wait some more seconds to let it switch to another mirror.
Otherwise, if LOANI seems really frozen (we have not experienced this behaviour for a few years now), you can download by your own means the relevant archives (for example
freetype-x.y.z.tar.bz2) and move them directly into the cache directory (by default,
LOANI-repository), among the other archives. Next time LOANI will be launched, it will take them into account, provided that they are not corrupted (i.e. their MD5 codes are right) or provided that strict mode is not enabled.
Still frozen (this should really almost never occur after that step)? After having waited enough (beware, some archives such as the one of gcc are very big), if the log files do not progress any more, the downloads (SVN and/or wget ones ) may encounter a network problem which happens on the user side.
Then one may stop LOANI, possibly get rid of all
wget processes still running (if any), and remove partially downloaded archives in
LOANI-repository (if strict mode is not chosen, since otherwise these archives would be taken as they are, next time LOANI is run).
After this cleaning, one may launch again LOANI a few moments later, and see whether networked operations are on a better route.
Error: Unable to extract XYZ, aborting.
[ -s | --strict ]), which would have triggered sooner a fatal error when the MD5 checksum of the downloaded package was found not matching the recorded one. You must have had a non-fatal warning for that, nevertheless. This may be the sign that a download failure occured, and that the retrieved archive was corrupted. Your best bet is to delete the corresponding archive in LOANI's cache (by default,
LOANI-repository) and re-launch LOANI.
Unable to pre-configure JPEGLibrary, host detection failed and there is no host work-around for your platform.
ltconfig, which is not always able to guess the underlying platform. We made a workaround for the most common Linux case (
i686-pc-linux-gnu), but your platform has still some problems. Please send us a Request For Enhancement, we will add your platform support as soon as possible.
This can happen if SVN is being used but
--currentSVN LOANI option is not selected, and if you have bad luck.
Long story short, in the LOANI tarball there is a (often recent) version of
loani-versions.sh which is the centralised place where tool versions are defined. If the
--currentSVN option is not selected, then LOANI will use a SVN tag to retrieve tagged latest stable versions for all files, including a
loani-versions.sh which dates back to this stable version.
It might differ from the one of the tarball, which explains why conflicts may occur. Based on the tarball, recent tools would have already been downloaded indeed, whereas the tagged code would demand older ones.
This is clearly a bug (see support), whose origin is to be found in too few stable tags being put. Adding
--currentSVN to the
loani.sh command line could fix it, in the lucky and most unlikely case where the SVN tree is not broken at the moment.
To get rid of the ambiguity between C and C++ compilers (partly due to the meaning of the CC environment variable and the allegation of gcc "able to distinguish between C and C++ sources"), LOANI will let the two environment variables
C_COMPILER (for C compiler) and
CPP_COMPILER (for C++ compiler) eclipse all other, including CC. If one of the two is needed and if it does not point towards a valid executable, an attempt will be made to respectively find gcc and g++. On failure, LOANI will fall back to CC, if set, hoping it will match the need.
If, as it would be normal, you are bothered by these build issues, just use the
--buildTools option and let LOANI take care of it!
Check that SourceForge really granted your user the right to access the developer SVN server, thanks to:
df -k .): LOANI performs some rough size estimates, but may be wrong. If it fails and little room remains, you have your first suspect. If the space left is not guilty, and if you are using Windows, some random errors actually seem to happen when using Cygwin. We noticed that sometimes some executables are not found whereas they are here, or some md5sum checkings fail whereas the sums should match. Try to re-launch LOANI, the outcome might be more satisfying, even though we are not fond of non-deterministic software.
If you have fancy compilers (for instance,
gcc 2.96) or even better no C++ compiler, and if you did not select the
--buildTools option (that would compile and install for you a recent gcc; by the way, please remember that a compiler is needed to compile a compiler!), expect having some trouble configuring Ceylan and OSDL.
gcc 2.95.4, which seems to have problems handling some iostream operations (ex: with
istringstream). As that same compiler seems to fail compiling a more recent version of itself (namely, the bootstrap of
--buildToolsLOANI option might not help you. The most simple way of dealing with this issue is to upgrade first your compiler thanks to your distribution (rpm, apt-get, emerge etc.).
Error: Unable to pass OSDL tests
No available video device), check that the user can display windows indeed, with respect to the X server (ex: test with
erlang/common/src, short of finding the
--OrgeToolsoption (recommended), or install the
C:\LOANI-install), as various tools may fail when paths become too long.
--sourceforgeoption (useful for developers), you retrieve the current code, whereas regularly the SVN is broken, as one could expect for in-development versions.
glxinfoshowing direct rendering, fails with
X11 driver not configured with OpenGL
Still out of luck? Still stuck with that bloody software? Nothing above helped you? Two solutions remain for the poor lonesome user:
LOANI.log, the text file where all LOANI operations are logged. This file is to be found in the directory where you executed LOANI, and is very useful to be looked at, including while LOANI is running. To do so, use
tail -f LOANI.login another terminal and lines will be shown as soon as they are output. Most of the errors should be easy fixed that way, notably if one uses too the
loani.sh -d [...]): in this case, more debug information will be displayed on screen. This option stands for debug mode, and ensures that LOANI is more verbose while running
cd <where you extracted LOANI archive>; ./generateBugReport.shand follow the instructions) to our mail account dedicated to troubleshooting, osdl-loani-bugs at lists.sourceforge.net, we will do our best to investigate and overcome the issue
We will do our best to investigate thoroughly and solve you issue. It will be an efficient feedback for us, so that we keep the documentation and the code in an always-clean state.
We hope you will enjoy using LOANI and OSDL!
If you have information more detailed or more recent than those presented in this document, if you noticed errors, neglects or points insufficiently discussed, drop us a line!