Wesnoth 1.84 and 1.9 linux binaries

[eXcellent]

Hi,

i was interested in a binary of BfW 1.9 though alas, there is none, even though there are binaries for mac and windows.
Why is that? What's the rationale behind it?

Anyways, i took the time and gathered developer libaries and compiled BFW 1.9.
Are there people interested in it? If so, i could upoad it.
Of course, only if this is allowed by the developers.

On another note:
The latest release i can obtain as a Ubuntu user is 1.8 and there is no option, at least none that i cound make out, to update to 1.8.4.
(That of course would have be done by the ubuntu folks. I hear they are notified about the latest release. Even stranger is the fact that
the package named "wesnoth" is an outdated version and the 1.8 branch is called "wesnoth-1.8" making the "wesnoth" package more likely
to be installed. That package is from the 1.6 branch... go figure.)
Since people are should update to the latest stable version when they report on bugs and gameplay related issues.
What are people supposed to do? You hardly can demand that your average joe to compile it himself.
As far as i know there isn't even an unofficial (not to mention official) server to d/l it from.
Again, why is that so? Why not upload the linux binaries to sourceforge?
Every other O/S gets served only the linux crowd is left standing in the rain.

In short, what's the ratonale behind this strategy?

Hope i can improve a bit on the availability of this gem of free (gaming) software!

eXcellence

[silene]

i was interested in a binary of BfW 1.9 though alas, there is none, even though there are binaries for mac and windows.
Why is that? What's the rationale behind it?

You seem to think that a linux binary would work on any linux distribution. This is not true. Most likely, the binary you compiled would work only for people with the exact same ubuntu version on the exact same architecture, not counting that they should have installed all the dependencies.

[eXcellent]

Could you be somewhat more elaborate?
I guess i should have talked bout debian/ubuntu(and derived distros) but even then i don't see
what the problem could be?
I , of course, assume that the user has had an older version of wesnoth installed so there are the runtime libraries of , eg. SDL present.
Apart from that, what could be obstacles?

Right now, i just can't think of anything which would be a significant roadblock.

Thank your for your insight,

eXc

[silene]

Could you be somewhat more elaborate?
I guess i should have talked bout debian/ubuntu(and derived distros) but even then i don't see
what the problem could be?

Type "ldd path/to/wesnoth" in a console and look at the result. You will see about 70 lines like the following

Code: Select all

libpulsecommon-0.9.21.so => /usr/lib/libpulsecommon-0.9.21.so (0x00007fd5fdd35000)

All these lines are the runtime dependencies of your binary. Now, what happens if someone happens to not have (so)version 0.9.21 of libpulsecommon but another one? You will get an error.

All the 70 dependencies have to match! If there is even one that doesn't match, the game won't start, and you can't do anything about it.

That's why people need to have the exact same distribution as yours on the exact same architecture for your binary to be useful.

[eXcellent]

Would i not be possible to circumvent this by including these libraries in the game files?
Is there something which would speak against it apart form a bigger filesize?

[silene]

Would i not be possible to circumvent this by including these libraries in the game files?

No. The proper way is to compile a "static" binary. (You know that you have obtained a static binary once ldd doesn't output anything anymore.) I don't know if wesnoth can actually be linked statically. Ideally, you would pass --enable-static at configure time and it would work. But I somehow doubt anybody tried a static build for several years.

[pauxlo]

Would i not be possible to circumvent this by including these libraries in the game files?

No. The proper way is to compile a "static" binary. (You know that you have obtained a static binary once ldd doesn't output anything anymore.)

I wanted to ask where the difference is between those two, but I think I got it ... "including the libraries in the game files" is not the same as "including the libraries in the game executable". (Actually, you'll only include the needed parts of the libraries.)

[norbert]

But I somehow doubt anybody tried a static build for several years.

It fails when all the .o files are being glued together:

/usr/bin/ld: attempted static link of dynamic object `/usr/lib/libpangocairo-1.0.so'
collect2: ld returned 1 exit status

[Iris]

But I somehow doubt anybody tried a static build for several years.

It fails when all the .o files are being glued together:
/usr/bin/ld: attempted static link of dynamic object `/usr/lib/libpangocairo-1.0.so'

Of course, since it's trying to link a dynamic .so. You are supposed to install or compile the component as a static library — the component being in this case pango-cairo.

You hardly can demand that your average joe to compile it himself.

Wesnoth was one of the first applications I started compiling since I was stuck with an old distro, providing 0.9.6, and wanted the latest stable, and later, the development versions.

It was fun.

EDIT: actually, in theory it'd be possible to make a Wesnoth bundle for Linux that included its own set of library files, independent from the system's, and a wrapper script that configured the correct dynamic loader environment to override the system libraries with Wesnoth's provided set. This would lead to much pain to the hypothetical packager since he'd have to compile every individual library with all sorts of special options to ensure that they don't rely on particular aspects of his own system — and then, keep that up to date whenever we need a newer/fixed version of a library. Also, many of our libraries may actually need to know certain stuff about the system they are running on, particularly if they depend on specific resource files whose locations may vary on every distribution, or on every version of a framework.

So it might end up being too much pain for nothing.

There, that's the theory. The execution should be much simpler...right?

[Haudegen]

Wesnoth was one of the first applications I started compiling since I was stuck with an old distro, providing 0.9.6, and wanted the latest stable, and later, the development versions.

It was fun.

And it's fairly easy once you've installed all the dependencies. I use a simple shell script on Ubuntu to download the xdelta and compile the stable version (wesnoth_install.sh) and the development version (wesnoth_install.sh dev) respectively. Since the version numbering isn't guaranteed to be regular (there was a 1.8a IIRC), the user has to edit the version numbers manually when a new version is out.

Code: Select all

#!/bin/dash
set -e

if [ "$1" = "dev" ] ; then
    # development version
    old_vers="wesnoth-1.9.0"
    new_vers="wesnoth-1.9.1"
else
    # stable version
    old_vers="wesnoth-1.8.3"
    new_vers="wesnoth-1.8.4"
fi

delta=${old_vers}.tar-${new_vers}.tar.xdelta

sudo apt-get --assume-yes build-dep wesnoth-1.8
sudo aptitude --assume-yes install libboost-thread-dev

if [ ! -e /usr/bin/xdelta ] ; then
    sudo aptitude --assume-yes install xdelta
fi

mkdir -p ~/src

if [ -d ~/src/$old_vers ] ; then
    cd ~/src/$old_vers
    sudo scons uninstall
fi

cd ~/src

if [ ! -e ${new_vers}.tar ] ; then

    if [ ! -e $delta ] ; then
        wget http://sourceforge.net/projects/wesnoth/files/wesnoth/$delta/download
    fi

    if [ -e ${old_vers}.tar.bz2 ] ; then
        echo -n "Unpacking archive ... "
        bunzip2 ${old_vers}.tar.bz2
        echo done
    fi

    xdelta patch $delta ${old_vers}.tar ${new_vers}.tar
fi

tar xvf ${new_vers}.tar
cd $new_vers

if [ "$1" = "dev" ] ; then
    scons prefsdir=.wesnoth-dev program_suffix=-dev datadirname=wesnoth-dev wesnoth
else
    scons wesnoth
fi
sudo scons install

# clean up
cd ~/src
rm -f $delta
rm -f ${old_vers}.tar
sudo rm -rf $old_vers

The script is by no means stable, portable or beautiful, but it gets the job done on 7 ubuntu linux machines. Maybe it inspires someone to write his own installation script.