How to distribute Irrlicht on linux

vins · Post by **vins** » Fri Aug 14, 2009 9:59 pm

I'm not very experienced with linux and I don't know how to distribute any application/game I make with irrlicht on linux. I've compiled Irrlicht using Code::Blocks as a shared lib and it produced a file "libIrrlicht.so"; Then I compiled a simple code and the executable requires this file to run. So I copied it to /usr/lib and the file starts. But it doesn't seems the right way to me. What if there is already such file there and what if it's build with a newer/older version of Irrlicht. I tried to put the file in the path where the executable was but it still can't find it.

Any help, comment etc would be appreciated.
Thanks.

PS:
I maged to run the program using the terminal by first setting the library path with "export LD_LIBRARY_PATH=/:$LD_LIBRARY_PATH"; But it's inconvenient.

bitplane · Post by **bitplane** » Fri Aug 14, 2009 10:19 pm

I'm not sure about this (I've been investigating it myself) but I think the best solution at the moment is to static link your app, otherwise I think you'll have to make a package for Irrlicht and include it as a dependency to your deb/rpm. You can install Irrlicht as a shared library manually by doing make sharedlib followed by sudo make install, but until 1.6.0 this won't be forward compatible with new versions, the soname is libIrrlicht.so.1 which links to 1.5.X. This would work with libIrrlicht.so.1.5.1, but not with libIrrlicht.so.1.6.0 which won't be binary compatible. The soname in trunk is now libIrrlicht.so.Major.Minor, minor releases should be binary compatible (unless we screw up!)

Starting with 1.6 we hope to supply a deb package for Irrlicht, if you want to make your own earlier then you should adapt the makefile from svn trunk instead. Static linking is the simplest option at the moment.

edit: When I do work all this out, I'll write some kind of guide for properly packaging Irrlicht-based games for Linux.

bitplane · Post by **bitplane** » Fri Aug 14, 2009 10:51 pm

I just realised that I didn't make myself very clear!

The problems are:

1) Building the shared library

You compile as a shared object, which is called libIrrlicht.so.version and link against it with -lIrrlicht (easy).

2) Installing the shared library

At link time, the lib is given a "shared object name" or "soname", this is compiled into the binary and says which series it is. All libraries in the same series are binary compatible. In our case this should be libIrrlicht.so.Major.Minor, (the file name is libIrrlicht.so.Major.Minor.Release). The .so is copied to your libs dir (/usr/lib/ or /usr/local/lib/) and a symbolic file link is created to link libIrrlicht.so.Major.Minor to the real file, libIrrlicht.so.Major.Minor.Release. In future when you upgrade, the install process deletes the old binary, installs a new one and changes the symbolic link to point to the latest version in the current series.

When you compile your app, you explicitly link against the series libIrrlicht.so.Major.Minor, not -lIrrlicht (the latest version) or libIrrlicht.so.Major.Minor.Release (a specific release).

When a new minor version is installed, it gets a new symbolic link and binary (/usr/local/lib/libIrrlicht.so.1.6 -> libIrrlicht.so.1.6.0).

3) Packaging it all up.

The Irrlicht-1.5 package is submitted to the package repositories, it starts at 1.5.0 and but a Release version (1.5.1) will upgrade and overwrite the binary using the same symbolic link. You say that your game package has a dependency for Irrlicht-1.5, the latest version of Irrlicht-1.5 (1.5.1) will be installed by apt-get. Irrlicht 1.6 will have its own link and binary separate from the 1.5 or 1.7 series.

Caveat:

At least that's how I understand it, I'm new to this myself!

CuteAlien · Post by **CuteAlien** » Fri Aug 14, 2009 11:30 pm

Bitplane described the official way. But many applications which are released binary-only use another solution. They copy the shared libraries just in the same folder or in a subfolder and then instead of allowing to start the binary directly you start instead a script. And that script can set the LD_LIBRARY_PATH to find your own shared libraries.

If you have for example googleearth installed you can checkout how they do it.

There is yet another solution - by using rpath in the linker. I had used that in the past, but still needed the script to set the start directory because I never found out how to set relative folders. But then I stumpled recently upon an undocumented feature of ld called $ORIGIN which does exactly that. You can find more info about that here: http://linuxreviews.org/man/ld.so/. And no - I have no idea why they don't document one of the most useful features of ld...

speewave · Post by **speewave** » Sat Aug 15, 2009 3:49 am

if you distribute per distro rather than a plain old zip (such as a debian package for ubuntu\debian based distros) you can include it as a prerequisite or something like that so when it downloads, irrlicht will download and install or do what people do in the windows world, distribute the .so file with the package and keep it in the executables path (never done this, dont know if it works)

CuteAlien · Post by **CuteAlien** » Sat Aug 15, 2009 8:28 am

speewave wrote:if you distribute per distro rather than a plain old zip (such as a debian package for ubuntu\debian based distros) you can include it as a prerequisite or something like that so when it downloads, irrlicht will download and install or do what people do in the windows world, distribute the .so file with the package and keep it in the executables path (never done this, dont know if it works)

Automatic dependency downloading in debian works only if either the distro actually has the libraries as packages (not the case for Irrlicht to my knowledge) or if the user adds a site where you offer those packages as download to his sources.list (when using apt - some debian-clones switched to aptitude and I don't know yet how that works).

Putting the .so just beside the executable like you can do in Windows will not work on Linux. For that to work you have to use an rpath with $ORIGIN (but then you can even put it in sub-directories, which you can't on Windows).

hybrid · Post by **hybrid** » Sat Aug 15, 2009 12:03 pm

Copying to /usr/lib and running ldconfig should also work.

vins · Post by **vins** » Sat Aug 15, 2009 5:22 pm

Thank you for the answers. I have alredy tried with setting the LD_LIBRARY_PATH and it works but I'd better use the last code from trunk or wait for the next release and just copy the library to /usr/lib;

vins · Post by **vins** » Sat Aug 15, 2009 6:19 pm

CuteAlien, thanks for the tip about rpath and $ORGIN. It works wonderfull. Now it looks for libraries in its own dir too. So I can just distribute with libIrrlicht.so with it.

bitplane · Post by **bitplane** » Sat Aug 15, 2009 8:18 pm

I concur, cool tip about $ORIGIN, I could never get relative paths working either

randomMesh · Post by **randomMesh** » Sat Aug 15, 2009 10:18 pm

I suggest to make this thread sticky. Very useful information in here!

Edit:
Just for the records:

I tried to distribute an application on Linux using irrKlang.
Here's what you have to add to Eclipse's Linker settings:

-Wl,-R,'$$ORIGIN/./lib'

The $$ is for escaping the $.

Now you can have a lib directory in your applications root.

And don't forget to statically link -lpthread.