@tzlaine: I did not spent much time for now, but it is possible to statically link more libs. I forgot
the stdc++, thats one main lib which SHOULD be linked statically, because at almost every system there's another version of this lib installed. I cannot reproduce your result of starting Freeorion in 0.5 seconds, because the loader has to load every lib before it starts. Maybe on your system most of the libs are already in memory when you start FO? That is no camparison...
I have much experience in linking programs statically. You are NOT able to release a linux-version of FO without doing that, because you will find no-one which has all this dependencies installed at-once. Even if you are using Debian Edge, you will have to manually install many libs. Even an advanced linux-user will not manage this.
You mentioned libGLU on your system. If libGLU depends on another installed lib-version, than this version would be used. I do not see a problem there. libGL and libGLU are the only libs which i wanted to leave dynamically, because that are is the only code which can vary very much from system to system, depending on which version of GL is installed (mesa, nvidia, mga, ati...).
I had 3 people trying to test freeorion, and all were NOT
able to get it compiled because they could not get all the dependend libs installed. And even they were not able to run a dynamically linked binary, because of the same problem.
@charlieg: I am not used in working with autopackage. What is the advantage of using it? The name "package" sounds like it is a process beyond linking, meaning "packaging" the compiled binaries and resources.
@geofthemedio: Wesnoth is a very nice game
. But wesnoth does not need that much libs then FO does, and therefore can hardly be compared. And it does not depend on scons, which makes it easier to integrate it into an existing packaging-tool, like apt or rpm. Maybe i am wrong in that point, but I did not see scons beeing used before.