Fail to build on amd64

[Martin Quinson]

The Debian autobuilders tryied to build the lastest release from the source, and this failed with an error message that I fail to understand. The logs are here:
http://people.debian.org/~lucas/logs/2012/05/08/widelands_17-2_unstable.log

Not being able to rebuild from source makes the package unfit for the next release. This means that if I cannot fix the issue with the appropriate patch, widelands will not be part of the next Debian release.

Any help is welcomed.

[Jens Beyer (qcumber-some)]

It seems you are building with gcc-4.7.0.

I won't be surprised if this is the reason. The fail is somewhere within boost signals?!

Can you pull a gcc-4.5.x instead of gcc-4.7.0 for building widelands?

[Nasenbaer (nasenbaer)]

Jepp the logs show gcc4.7, so as stated in the release notes ( https://launchpad.net/widelands/+milestone/build-17 ):

> 1st) Compile time issues
> ------------------------
> * Widelands does not compile, if using gcc 4.7. Fix: add "#include <unistd.h>" to the file "src/main.cc"

[Jens Beyer (qcumber-some)]

This is bug 976551 which is very different to this one, from what I see in the logs.

[Hans Joachim Desserud (hjd)]

Thanks for forwarding this issue.

I am not sure how much it helps, but I have been able to compile latest* version of Widelands on Arch (32 bit) with gcc4.7 and boost1.49, so I am not sure why it would fail on Debian.

Do you know whether these rebuilds of Debian Unstable are done for multiple architectures at the same time or if they are done on separate occasions? Since the reported error was from 64 bit, I'm curious whether 32 bit has the same problem.

* development version, including the fix for gcc 4.7.

[Martin Quinson (mquinson)]

Short version
-------------
it seems that we need to make widelands buildable with gcc4.7

Long version
------------
In Debian, packages are routinely built for QA purposes. You first
have the build daemons:
https://buildd.debian.org/status/package.php?p=widelands&suite=sid

And then sometimes, Lucas and others rebuild the whole archive in some
specific settings to try to detect the bugs in advance. Here, he
probably tryied to recompile the whole debian archive with gcc 4.7.
This is perfectly valid because gcc 4.7 is one of the available
versions in debian unstable.

So, in contrary to what I said earlier, if we fail to fix that bug, we
won't be kicked out of the next stable because the bug is only for
"Debian unstable" while the next stable will be derivated from "Debian
testing", and gcc-4.7 didn't make it to testing yet.

But we still should try to fix it, that is, make widelands build with
gcc-4.7. This is particularly important because of:
http://packages.qa.debian.org/w/widelands.html

widelands 17 didn't make it to testing yet, only 17~rc2. So this bug
is preventing the final release from migrating to testing, although I
will probably trick to migrate anyway (like downgrading the bug since
gcc-4.7 is not in testing anyway).

Bye, Mt.

On Wed, May 09, 2012 at 06:37:06PM -0000, Hans Joachim Desserud wrote:
> Thanks for forwarding this issue.
>
> I am not sure how much it helps, but I have been able to compile latest*
> version of Widelands on Arch (32 bit) with gcc4.7 and boost1.49, so I am
> not sure why it would fail on Debian.
>
> Do you know whether these rebuilds of Debian Unstable are done for
> multiple architectures at the same time or if they are done on separate
> occasions? Since the reported error was from 64 bit, I'm curious whether
> 32 bit has the same problem.
>
> * development version, including the fix for gcc 4.7.
>
> ** Changed in: widelands
> Importance: Undecided => High
>
> ** Tags added: ftbfs
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/996965
>
> Title:
> Fail to build on amd64
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands/+bug/996965/+subscriptions

--
If you can't do it in ANSI C, it isn't worth doing.

[Jens Beyer (qcumber-some)]

From what I could get from this forum thread:

https://bbs.archlinux.org/viewtopic.php?id=138992

it seems that a rebuild of boost libraries with the new compiler (read: gcc-4.7.0) should solve this.

Martin, can you confirm if the libboost packages which are used in this build are already built by gcc-4.7.0?

[Martin Quinson (mquinson)]

On Thu, May 10, 2012 at 10:33:37AM -0000, Jens Beyer (Qcumber-some) wrote:
> >From what I could get from this forum thread:
>
> https://bbs.archlinux.org/viewtopic.php?id=138992
>
> it seems that a rebuild of boost libraries with the new compiler (read:
> gcc-4.7.0) should solve this.
>
> Martin, can you confirm if the libboost packages which are used in this
> build are already built by gcc-4.7.0?

It seems to me that the lastest libboost in debian unstable on amd64
were built with gcc-4.6
https://buildd.debian.org/status/fetch.php?pkg=boost1.49&arch=ia64&ver=1.49.0-3&stamp=1336330572

I'm CCing the debian bug for information archival.

Thanks investiguating this, Mt.

--
Le pointeur est aux données ce que la boucle while est au code.

[Hans Joachim Desserud (hjd)]

Please note that even with rebuilt boost libraries, the patch from bug 976551 will be needed to successfully compile Widelands with gcc 4.7. As far as I can see this is not applied to the Debian package. (Yes, this not included in build17 as it was discovered too close to the release. See the bug report for more details.)

[David Allwicher (aber)]

https://code.launchpad.net/ubuntu/quantal/+source/widelands/1:17-2

The ubuntu release is fine. I would consider this fixed, because this issue should have hit other packages as well and the debian builders will very likely make sure that boost is proper destrooted in a next rebuild.

[Martin Quinson (mquinson)]

On Sun, May 13, 2012 at 01:05:06PM -0000, David Allwicher wrote:
> https://code.launchpad.net/ubuntu/quantal/+source/widelands/1:17-2
>
> The ubuntu release is fine. I would consider this fixed, because this
> issue should have hit other packages as well and the debian builders
> will very likely make sure that boost is proper destrooted in a next
> rebuild.

Could you please be a bit more explicit about destrooting? I'm
considering reassigning that bug to boost if it's the case. Any link
to similar issues somewhere?

Thanks, Mt.

[David Allwicher (aber)]

The problem itself seems to be hidden inside gcc and not widelands nor boost, but it seems to be rare and there is a simple solution. We can link boost dynamic and the problem will go away.
I assumed debian will build all packages using the same compiler, which will also fix the problem.

[Jens Beyer (qcumber-some)]

I am all for dynamic linking, if not for fixing this bug, then for reducing complexity in the build.

[Martin Quinson (mquinson)]

On Mon, May 14, 2012 at 02:09:55PM -0000, David Allwicher wrote:
> The problem itself seems to be hidden inside gcc and not widelands nor boost, but it seems to be rare and there is a simple solution. We can link boost dynamic and the problem will go away.
> I assumed debian will build all packages using the same compiler, which will also fix the problem.
>
> ** Patch added: "Boost_USE_DYNAMIC_LIBS.diff"
> https://bugs.launchpad.net/widelands/+bug/996965/+attachment/3146026/+files/Boost_USE_DYNAMIC_LIBS.diff

Ok, thanks for this simple solution. We'll try to apply it to the
debian package and see if it helps. The fact is that there is 3
versions of gcc in debian unstable right now, and I think that we have
to be buildable with all of them.

Thanks again for your help, guys.
Mt.

--
Le sens commun n'est pas si commun (Common sense is not so common).
  -- Voltaire

[Jens Beyer (qcumber-some)]

Now that this is confirmed as working, I've pushed this to trunk. Setting Fix committed.

[Nasenbaer (nasenbaer)]

Thanks for the fix Jens.
Your commit message says, that now the dynamic libraries are always used. So there is no way left to build a (almost) completely statically linked binary?
Of course the question arises, in what case such a binary would be wise, but I guess at least for Windows, that's the way we would like to go. But I may be wrong.

So is it possible to still compile against static libraries?

[Jens Beyer (qcumber-some)]

I guess the commit message could have been clearer.
Windows (to be clear MSVC) is handled in a completely different way and has not been touched by the commit (at least that's what I hope/understand from the code in src/CMakeLIsts.txt).

For everything using standard build toolchain (so at least Linux/*BSD/MacOS) with GCC/LLVM your statement is true, there is no way to have an entirely static build now. But there has not been a way before without tinkering with the CMakeLIsts files, so I thought this wouldn't be dramatic.
If we want to enable static linking with standard build toolchain on Linux/*BSD/MacOS with GCC/LLVM, we should make a proper approach to do this.
But we should create a new bug for this, I think. We should then also make sure if we want to officially support static building for everyone or maybe issue a warning if static building is enabled that the user doing so is on his own when it comes to such issues like we had in this bug. Such issues are very hard to trace since it depends heavily on the system where the error occurs.

[David Allwicher (aber)]

https://bugs.launchpad.net/bugs/996965

[David Allwicher (aber)]

https://bugs.launchpad.net/widelands/+bug/548959
dooh

[Nasenbaer (nasenbaer)]

@#16 I agree.

And thanks for the link David :)

[SirVer (sirver)]

Released in build-18 rc1.