Build 18-rc1 FTBFS on Debian (sparc)

[Hans Joachim Desserud]

The release candidate has already been picked up and packaged for Debian unstable [1]. However, it failed to build on a couple of architectures, namely mips [2], ia64 and sparc. Spoke a bit with the Debian maintainer, emptty, earlier today on IRC and the main problem is not compiling on sparc. That is considered a release critical issue in Debian, meaning the package will not go into the stable release. :(

See https://buildd.debian.org/status/package.php?p=widelands for details/logs/error messages.

Tentatively targeting this for the second release candidate for now, hoping someone will take a look at and resolve this.

[1] http://packages.qa.debian.org/w/widelands.html
[2] By getting GCC to seg fault, no less.

[SirVer (sirver)]

Seems like there isn't much we can do about that: The buildlog [1] for sparc shows pretty clearly that the compiler is barfing about boost::signal2 - we depend on that and it as standard a library as it gets. And seriously, who would want to play a Video game on sparcs anyways? Pretty ridiculous that this is a show stopper for them.

[1] https://buildd.debian.org/status/fetch.php?pkg=widelands&arch=sparc&ver=1%3A18~rc1-1&stamp=1392074771

So from my point of view this is out of our hands - there is nothing that we could do except for going back to boost::signal which is deprecated.

[SirVer (sirver)]

Is it possible to get the debian maintainer involved in this bug report? There must be other software that depends on boost::signal2 in debian.

[Jens Beyer (qcumber-some)]

Just a little thinking about this...

http://packages.debian.org/jessie/sparc/libboost1.54-dev/filelist shows it includes the signals2 files. This, and the fact that signals2 should be header-only (in difference to signals which was partly binary AFAIK), I see no reason why this should not work? Maybe there is a different dependency problem?

[SirVer (sirver)]

As discussed with emptty (the debian maintaner) in IRC, I closed this as invalid as it is not a Widelands issues.

fwiw I still hope that we do not need a second release candidate.

[Teppo Mäenpää (kxq)]

I installed Debian Wheezy on top of qemu-powered sparc. Base system only, nothing else. Then I pulled widelands build-deps, and R18rc1 sources. The compile script built the binary fine without any problems.

I did not try actually playing the game, emulating sparc on x86_64 is too slow.

[Hans Joachim Desserud (hjd)]

> I installed Debian Wheezy on top of qemu-powered sparc.

That's interesting. The boost version in Wheezy (the current stable Debian release) is 1.49, while testing/Jessie and unstable has 1.54 [1]. I am not sure what is going on, but whatever it is likely broke somewhere between those two releases. The fact that WL builds with an older release might indicate the problem resides in boost, especially considering it builds fine on other architectures without any changes.

[1] http://packages.qa.debian.org/b/boost-defaults.html

[SirVer (sirver)]

There is nothing magical going on an this is indeed a (pretty) well known bug: essentially boost introduced some move constructors, but did not properly define their copy constructors. Early gcc violated the c++11 standard and compiled the code just fine, later gcc did implement the standard correctly and refuses to compile the boost code. So it is a nice interlock between a bug in boost and a bug in gcc. Further reading: http://stackoverflow.com/questions/10440860/boost-intrusive-unordered-set-broken-in-1-48-with-gcc-in-c11-mode

[Hans Joachim Desserud (hjd)]

Fwiw, I saw that Debian testing (i.e. the basis for the nex, upcoming release) has removed the sparc architecture all-together.

For details see https://lists.debian.org/debian-devel-announce/2014/04/msg00012.html