Statically linked Linux-version

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Post Reply
Message
Author
User avatar
kroddn
Static Linker
Posts: 347
Joined: Thu Jun 28, 2007 10:28 am

Statically linked Linux-version

#1 Post by kroddn »

Hello there,

I figured out how to link the project statically. I have published some versions here:

http://freeorion.psitronic.de/

Read the installation HOWTO at http://freeorion.psitronic.de/README.txt. Please have a look at the nightly builds!

This latest versions can be installed by using a graphical Setup (Loki-Installer) on almost every modern linux-distribution. If you encouter problems, feel free to report them here.

Beware: you will need a graphics-driver that supports openGL 2.0! Some ATI Cards are know to NOT work.

Debugging: on http://freeorion.psitronic.de/download/nightly/ there are debugging symbol archives for current versions. Extract the *.dbg files into the application directory of your installation, so that for example freeorion and freeorion.dbg reside in the application directory.

Try out!
/Edit 2010-03-19: Release Revision FO 3388/GG 804) available.

/Edit 2009-05-26: Release Revision FO 3099/GG 757) available. Ogre modules statically linked.
/Edit 2009-05-20: Release Revision FO 3066/GG 748) available. Loki setup/uninstall fixed.
/Edit 2009-05-02: Release Revision FO 3009/GG 735) available. Contains OGRE 1.6.2 shared libs and runtime modules.
/Edit 2009-03-16: Release v0.3.12.1 Release Revision FO 2918/GG 711) available. Contains OGRE shared libs and runtime modules.
/Edit 2009-01-26: Release Revision 2771/GG 700) available. Bugfix for kernel versions lower than 2.6.22
/Edit 2009-01-11: Release v0.3.11 (SVN Revision 2732/GG 695) - also available on SourceForge
GCC 4.3 compiled, with shipped python fallback. See viewtopic.php?f=9&t=2315

/Edit 2009-01-07: Release Revision 2727/GG 694) available. GCC 4.3 compiled, with shipped python fallback. See viewtopic.php?f=9&t=2315
/Edit 2009-01-06: Release Revision 2723/GG 693) available. GCC 4.3 compiled, with shipped python fallback. See viewtopic.php?f=9&t=2315
/Edit 2008-07-16: Release Revision 2642/GG 655) available. GCC 4.3 compiled, with shipped python fallback. See viewtopic.php?f=9&t=2315
/Edit 2008-07-14: Release Revision 2641/GG 655) removed because of buggy graphviz linking
/Edit 2008-06-25: Release Revision 2607/GG 651) available, using a Loki-Installer
/Edit 2008-05-15: Release Revision 2570/GG 648) available, using a Loki-Installer
/Edit 2008-05-15: Release Revision 2548/GG 647) available, using a Loki-Installer
/Edit 2008-04-12: Release v0.3.9 (Revision 2481/GG 645) available, using a Loki-Installer
/Edit 2008-04-11: New Revision 2477 (GG 645) available, using a Loki-Installer
/Edit 2008-04-10: New Revision 2473 (GG 645) available, using a Loki-Installer
/Edit 2008-04-08: New Revision 2464 (GG 645) available, using a Loki-Installer
/Edit 2008-02-25: New Revision 2355 available


Some Background-Information:
If FO is compiled dynamically, it is almost impossible to run the built binaries on any other system, because the dependencies will have to be exactly the same on the other system. Linking the code into the binary statically has the advantage to avoid these dependencies. There are still some direct dependencies left, for example the libGL and libX11 - but these are well standardized libraries and will vary on each system, so these stay linked dynamically.

Now there are not much dependencies left for executing:

Code: Select all

     
# ldd -u freeorion
        /usr/lib/libGL.so.1
        /usr/lib/libGLU.so.1
        /lib/libpthread.so.0
        /usr/lib/libX11.so.6
In comparison to the version before:

Code: Select all

        linux-gate.so.1 =>  (0xffffe000)
        libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb7e62000)
        libGiGiSDL.so => not found
        libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7da8000)
        libGiGiNet.so => not found
        libIL.so.1 => /usr/lib/libIL.so.1 (0xb7c9c000)
        libILU.so.1 => /usr/lib/libILU.so.1 (0xb7c83000)
        libILUT.so.1 => /usr/lib/libILUT.so.1 (0xb7c7e000)
        libGiGi.so => not found
        libboost_signals-gcc41-mt-1_34.so.1.34.0 => /usr/lib/libboost_signals-gcc41-mt-1_34.so.1.34.0 (0xb7c6b000)
        libboost_filesystem-gcc41-mt-1_34.so.1.34.0 => /usr/lib/libboost_filesystem-gcc41-mt-1_34.so.1.34.0 (0xb7c5f000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0xb7bff000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7b7f000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7b15000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7aff000)
        libboost_serialization-gcc41-mt-1_34.so.1.34.0 => /usr/lib/libboost_serialization-gcc41-mt-1_34.so.1.34.0 (0xb7a9a000)
        libboost_iostreams-gcc41-mt-1_34.so.1.34.0 => /usr/lib/libboost_iostreams-gcc41-mt-1_34.so.1.34.0 (0xb7a90000)
        libboost_python-gcc41-mt-1_34.so.1.34.0 => /usr/lib/libboost_python-gcc41-mt-1_34.so.1.34.0 (0xb7a4d000)
        libalut.so.0 => /usr/lib/libalut.so.0 (0xb7a45000)
        libopenal.so.0 => /usr/lib/libopenal.so.0 (0xb7a08000)
        libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0xb7a01000)
        libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb79d9000)
        libogg.so.0 => /usr/lib/libogg.so.0 (0xb79d4000)
        libgraph.so.3 => /usr/lib/libgraph.so.3 (0xb79ca000)
        libcdt.so.3 => /usr/lib/libcdt.so.3 (0xb79c5000)
        libgvc.so.3 => /usr/lib/libgvc.so.3 (0xb7963000)
        liblog4cpp.so.4 => /usr/lib/liblog4cpp.so.4 (0xb7935000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xb791e000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7833000)
        libm.so.6 => /lib/libm.so.6 (0xb780c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7801000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb77e9000)
        libc.so.6 => /lib/libc.so.6 (0xb76a6000)
        libdl.so.2 => /lib/libdl.so.2 (0xb76a2000)
        libutil.so.1 => /lib/libutil.so.1 (0xb769e000)
        libasound.so.2 => /usr/lib/libasound.so.2 (0xb75da000)
        libartsc.so.0 => /usr/lib/libartsc.so.0 (0xb75d4000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb75d0000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb75cc000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7539000)
        libesd.so.0 => /usr/lib/libesd.so.0 (0xb7530000)
        libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb750c000)
        libaudio.so.2 => /usr/lib/libaudio.so.2 (0xb74f7000)
        libXt.so.6 => /usr/lib/libXt.so.6 (0xb74a6000)
        libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb7450000)
        libfusion-0.9.so.25 => /usr/lib/libfusion-0.9.so.25 (0xb744a000)
        libdirect-0.9.so.25 => /usr/lib/libdirect-0.9.so.25 (0xb743b000)
        libvga.so.1 => /usr/lib/libvga.so.1 (0xb73db000)
        libaa.so.1 => /usr/lib/libaa.so.1 (0xb73c0000)
        libcaca.so.0 => /usr/lib/libcaca.so.0 (0xb73b7000)
        libcucul.so.0 => /usr/lib/libcucul.so.0 (0xb733a000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7317000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb72f7000)
        libtiff.so.4 => /usr/lib/libtiff.so.4 (0xb72a3000)
        libmng.so.1 => /usr/lib/libmng.so.1 (0xb7231000)
        librt.so.1 => /lib/librt.so.1 (0xb7228000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb713c000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb712e000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7129000)
        libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb711f000)
        libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb710f000)
        libpathplan.so.3 => /usr/lib/libpathplan.so.3 (0xb7107000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb70e7000)
        libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb70e0000)
        /lib/ld-linux.so.2 (0xb7fa5000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0xb70d7000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0xb70bf000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xb707c000)
        libslang.so.2 => /lib/libslang.so.2 (0xb6fbd000)
        libgpm.so.1 => /usr/lib/libgpm.so.1 (0xb6fb6000)
        liblcms.so.1 => /usr/lib/liblcms.so.1 (0xb6f83000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6f80000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6f7b000)

Last edited by kroddn on Fri May 23, 2008 11:08 am, edited 11 times in total.

tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Statically linked Linux-version

#2 Post by tzlaine »

What is the advantage of linking statically?

User avatar
kroddn
Static Linker
Posts: 347
Joined: Thu Jun 28, 2007 10:28 am

Re: Statically linked Linux-version

#3 Post by kroddn »

You can run the game on more platforms, the user will not have to install all the dependencies.

For example, FO cannot be compiled on Debian 4.0 (edge), because some libs are missing. I managed to install them, but a user would NOT be able to run the dynamically linked binary on his system. This binary even runs on debian 3.1, and I know from one user who runs it on SUSE10.2.

Another very great advantage is, that the game starts/runs much faster. The start of FO is now about 1-2 Seconds, while before it took about 40 seconds (the time is spent loading dyn-libs).

tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Statically linked Linux-version

#4 Post by tzlaine »

I have a fully dynamically-linked FO on my system that takes about 0.5 seconds to load. This is highly variable on different systems. Also, I hope you are not claiming that the static version is somehow portable! Notice the dependency on libstdc++.so.5 in the static version? That will not work on my system, because my libGLU.so.1 depends on libstdc++.so.6. Link in both libstdc++.so.5 and libstdc++.so.6 and you get nondeterministic behavior!

The bottom line is that, due to radical differences in the GCC C++ ABIs from one release to the next, there is virtually no portability guarantee you can make for Linux C++ programs, unless you guarantee source-level portability and have users compile everything themselves.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Statically linked Linux-version

#5 Post by Geoff the Medio »

It may not be universally portable, but isn't this better than nothing for people who want to check out FreeOrion, but aren't able or willing to spend the time and effort to get it compiled, but do happen to have a distribution and other dependencies that are compatible with those used?

If the binaries only work for certain (versions of) distributions, then they could be released specifically for those distros and versions. This appears to be what is done for Wesnoth Linux binaries.

charlieg
Space Floater
Posts: 38
Joined: Tue May 25, 2004 1:59 pm

Re: Statically linked Linux-version

#6 Post by charlieg »

You could try something like autopackage which takes such issues into account.
Free Gamer - open source games resource
FreeGameDev - Free Software game community

User avatar
kroddn
Static Linker
Posts: 347
Joined: Thu Jun 28, 2007 10:28 am

Re: Statically linked Linux-version

#7 Post by kroddn »

@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.

User avatar
kroddn
Static Linker
Posts: 347
Joined: Thu Jun 28, 2007 10:28 am

Re: Statically linked Linux-version

#8 Post by kroddn »

I updated the statically linked "Distribution".

The tar.gz contains the binaries AND data. You can download and untar it anywhere on your system. The following requirements need to be fullfilled:
  • libncurses / ncurses
  • libgpm / gpm
  • libGL and libGLU (should be installed by default)
There's a README.txt with installation manual:
http://freeorion.psitronic.de/README.txt

The actual version can be downloaded here:
http://freeorion.psitronic.de/

/Edit Kroddn #1: UPDATED!
- fixed a bug Error: Layout type: "dot" not recognized. Use one of:" resulting from missing runtime-dynamically loaded graphviz-libs. These libs are now statically linked, too.
md5sum: a8555c63017c31590b4fa36b881023cb



/Edit Kroddn #2: UPDATED!
- Python2.4 statically linked.
- Fixes for SuSE 10.2. runs on VMware with SuSE 10.2 (but 1 FPs :-) )
- User reports: runs fine on Ubuntu Gutsy
- Another one reports: runs fine on Kubuntu 7.04 Feisty
md5sum: 63444e3c41eed93686bef5ce28135f82
Last edited by kroddn on Tue Jul 17, 2007 9:09 am, edited 2 times in total.

tzlaine
Programming Lead Emeritus
Posts: 1092
Joined: Thu Jun 26, 2003 1:33 pm

Re: Statically linked Linux-version

#9 Post by tzlaine »

Until you link everything together statically and distribute a giant executable, you will continue to have ABI problems and undefined behavior on some systems. It's that simple.

User avatar
kroddn
Static Linker
Posts: 347
Joined: Thu Jun 28, 2007 10:28 am

Re: Statically linked Linux-version

#10 Post by kroddn »

So, what is better than? Having an executable, which has some dependencies left, or having no executable at all?

I don't think that it is a good idea to link everythink statically. For example, on my systeme there are some nvidia-libs. That code won't work on systems without nvidia-modified kernel.

For me it seems that you are not interested in distributing an easy-to-install linux-version. Do you believe that most linux-users will be able to compile FO? I do not think so. Look at some loki games, they are statically linked and come with an easy-to-use installer. And these games work an the majority of available linux versions.

User avatar
Alberjohns
Space Floater
Posts: 22
Joined: Sat Feb 14, 2004 9:15 am

Re: Statically linked Linux-version

#11 Post by Alberjohns »

kroddn wrote: Do you believe that most linux-users will be able to compile FO? I do not think so. Look at some loki games, they are statically linked and come with an easy-to-use installer. And these games work an the majority of available linux versions.
I agree kroddn. I have downloaded your staticly linked version, and it seems to work very well. I use Ubuntu Feisty. Thanks for providing it. I think it would be a good idea for the main web page of FreeOrion to provide a web link to this version for those who want to try it. It will probably work for most people. For those people who cannot make it work, they will have to compile FO themselves, assuming they are capable of doing so. I know it took me a very long time and a lot of work to learn how to compile it.

User avatar
kroddn
Static Linker
Posts: 347
Joined: Thu Jun 28, 2007 10:28 am

Re: Statically linked Linux-version

#12 Post by kroddn »

The newest version (which I currently only have local) does not even need libstdc++. Currently I don't know from anyone who was not able to run that version.

mikko.ohtamaa
Space Krill
Posts: 2
Joined: Tue Jul 24, 2007 1:45 pm

Re: Statically linked Linux-version

#13 Post by mikko.ohtamaa »

This is just great! Thank you very much for this statically linked version.

It's hard for even advanced Linux user to hunt down all the obscure dependendies of FreeOrion and try to to build it. This just works (tm). I really would love to see the statically linked version in the official distribution too. People really don't care about bandwidth or loading times, as long as it runs.

Ps. I can provide mirror server/server space if needed

User avatar
kroddn
Static Linker
Posts: 347
Joined: Thu Jun 28, 2007 10:28 am

Re: Statically linked Linux-version

#14 Post by kroddn »

The latest Revision 2195 is now available statically linked.

This version does not run any more on my debian sarge machine, quitting with an "API error", so maybe other distibutions with older libraries do not work.

Tested are:
Debian Edge
OpenSuSE 10.2

Download:
http://freeorion.psitronic.de/

I think because of the GPL licencing I will have to include the sources from which the source was build. But I do not know for now if I have to include it directly in this download or if i can have it downloadable separately. Does anybody know?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13586
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Statically linked Linux-version

#15 Post by Geoff the Medio »

kroddn wrote:I think because of the GPL licencing I will have to include the sources from which the source was build. But I do not know for now if I have to include it directly in this download or if i can have it downloadable separately. Does anybody know?
See here. The sources have to be available "from the same place". A link to your file and a link to the appropriate revision at sourceforge should be adequate.

Post Reply