FreeOrion

Forums for the FreeOrion project
It is currently Sat Apr 21, 2018 9:53 am

View unanswered posts | View active topics


Board index » Development » Programming

All times are UTC




Post new topic Reply to topic  Page 1 of 8
  [ 112 posts ]  Go to page 1, 2, 3, 4, 5 ... 8  Next
  Print view Previous topic | Next topic 
Author Message
kroddn
PostPosted: Sat Jul 07, 2007 6:38 pm 
Offline
Static Linker
User avatar

Joined: Thu Jun 28, 2007 10:28 am
Posts: 347
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:
     
# 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:
        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.

Top
 Profile  
 
tzlaine
PostPosted: Sun Jul 08, 2007 5:30 am 
Offline
Programming Lead Emeritus
User avatar

Joined: Thu Jun 26, 2003 1:33 pm
Posts: 1092
What is the advantage of linking statically?
Top
 Profile  
 
kroddn
PostPosted: Sun Jul 08, 2007 6:43 am 
Offline
Static Linker
User avatar

Joined: Thu Jun 28, 2007 10:28 am
Posts: 347
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).
Top
 Profile  
 
tzlaine
PostPosted: Sun Jul 08, 2007 7:20 pm 
Offline
Programming Lead Emeritus
User avatar

Joined: Thu Jun 26, 2003 1:33 pm
Posts: 1092
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.
Top
 Profile  
 
Geoff the Medio
PostPosted: Sun Jul 08, 2007 7:56 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12171
Location: Munich
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.
Top
 Profile  
 
charlieg
PostPosted: Sun Jul 08, 2007 11:26 pm 
Offline
Space Floater

Joined: Tue May 25, 2004 1:59 pm
Posts: 37
You could try something like autopackage which takes such issues into account.

_________________
Free Gamer - open source games resource
FreeGameDev - Free Software game community
Top
 Profile  
 
kroddn
PostPosted: Mon Jul 09, 2007 10:10 am 
Offline
Static Linker
User avatar

Joined: Thu Jun 28, 2007 10:28 am
Posts: 347
@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.
Top
 Profile  
 
kroddn
PostPosted: Mon Jul 09, 2007 11:55 am 
Offline
Static Linker
User avatar

Joined: Thu Jun 28, 2007 10:28 am
Posts: 347
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.

Top
 Profile  
 
tzlaine
PostPosted: Mon Jul 09, 2007 6:58 pm 
Offline
Programming Lead Emeritus
User avatar

Joined: Thu Jun 26, 2003 1:33 pm
Posts: 1092
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.
Top
 Profile  
 
kroddn
PostPosted: Mon Jul 09, 2007 7:19 pm 
Offline
Static Linker
User avatar

Joined: Thu Jun 28, 2007 10:28 am
Posts: 347
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.
Top
 Profile  
 
Alberjohns
PostPosted: Sun Jul 15, 2007 3:02 pm 
Offline
Space Floater
User avatar

Joined: Sat Feb 14, 2004 9:15 am
Posts: 22
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.
Top
 Profile  
 
kroddn
PostPosted: Mon Jul 16, 2007 7:15 pm 
Offline
Static Linker
User avatar

Joined: Thu Jun 28, 2007 10:28 am
Posts: 347
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.
Top
 Profile  
 
mikko.ohtamaa
PostPosted: Tue Jul 24, 2007 2:01 pm 
Offline
Space Krill

Joined: Tue Jul 24, 2007 1:45 pm
Posts: 2
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
Top
 Profile  
 
kroddn
PostPosted: Tue Jul 24, 2007 9:03 pm 
Offline
Static Linker
User avatar

Joined: Thu Jun 28, 2007 10:28 am
Posts: 347
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?
Top
 Profile  
 
Geoff the Medio
PostPosted: Tue Jul 24, 2007 9:30 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12171
Location: Munich
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.
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 8
  [ 112 posts ]  Go to page 1, 2, 3, 4, 5 ... 8  Next

Board index » Development » Programming

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group