Boost 1.69 breaks compiling

[Tino]

Latest Boost breaks widelands at least on windows, see recent Appveyor builds.

=> https://github.com/boostorg/logic/pull/5

It seems that also the FindBoost.cmake by Cmake needs an update...

[kaputtnik (franku)]

Hm, the link you postet is about bool/tribool, but the the error on appveyor is about std::snprintf?

Can you explain the context?

Since i will be soon affected by this due to my linux distribution, i would be glad if the underlying bug will be fixed.

[kaputtnik (franku)]

Luckily i have no problems with boost 1.69. Used packages:

Name : boost
Version : 1.69.0-1
Architektur : x86_64

Name : boost-libs
Version : 1.69.0-1
Architektur : x86_64

Test results:

    Built target wl_tests
Test project /home/kaputtnik/widelands-repo/trunk/build
    Start 1: test_economy
1/4 Test #1: test_economy ..................... Passed 0.19 sec
    Start 2: test_io_filesystem
2/4 Test #2: test_io_filesystem ............... Passed 0.09 sec
    Start 3: notifications_test
3/4 Test #3: notifications_test ............... Passed 0.01 sec
    Start 4: test_scripting
4/4 Test #4: test_scripting ................... Passed 0.02 sec

100% tests passed, 0 tests failed out of 4

I get a deprecation warning though:

   Building CXX object src/random/CMakeFiles/random.dir/random.cc.o
In file included from /usr/include/boost/random/detail/integer_log2.hpp:19,
from /usr/include/boost/random/detail/large_arithmetic.hpp:19,
from /usr/include/boost/random/detail/const_mod.hpp:23,
from /usr/include/boost/random/detail/seed_impl.hpp:26,
from /usr/include/boost/random/mersenne_twister.hpp:30,
from /usr/include/boost/uuid/random_generator.hpp:17,
from /usr/include/boost/uuid/uuid_generators.hpp:17,
from /home/kaputtnik/widelands-repo/trunk/src/random/random.cc:26:
    /usr/include/boost/pending/integer_log2.hpp:7:59: Anmerkung: #pragma message: This header is deprecated. Use <boost/integer/integer_log2.hpp> instead.
    BOOST_HEADER_DEPRECATED("<boost/integer/integer_log2.hpp>");

[hessenfarmer (stephan-lutz)]

ok I got Boost 1.69 working in my local msys environment.

The change that causes the fail can be circumvented by editing libintl.h

line 369 has to be changed from

#if 1 to
#if 0

this breaks the link to libintl_snprintf so that std::snprintf works

I think this bug is unique to Mingw and therefore does not effect other build environments.

[Tino (tino79)]

Yes, this is caused by boost using a default c11++ std:snprintf (see this discussion https://github.com/mxe/mxe/issues/1104):

\include\boost\system\detail\system_category_win32.hpp => line 52.

Removing std:: here does circumvent the error, too.

But i am also experiencing the error, that now widelands (or some wl libs) require linking boost thread:

C:\data\wlwl>ninja -j1 widelands
ninja: error: '/c/bin/mingw/lib/libboost_thread.a', needed by 'src/widelands.exe', missing and no known rule to make it

The file exist of course and some wl libs include it ok. I cannot figure out how to correct this dependency due to those really weird structure of WLFunctions.cmake which does the boost including and target linking on USES_BOOST_REGEX...

[hessenfarmer (stephan-lutz)]

I have not seen the error mentioned by Tino in my environment so far.

Until now I only did 64bit release builds, but I will try the other build types tonight.

Anyhow this is a MINGW only issue and therefore does not affect Linux and OSX. So if we can provide windows builds, this bug shouldn't stop B20 from my point of view.

[Tino (tino79)]

Most likely you are linking dynamically, and "my" issue is caused by me trying to link everything statically...

So to be clear, we are talking about 3 bugs currently troubling windows builds:
- Appveyor does only build x64, x86 was disabled at some point (not sure, why exactly)
- Boost 1.69 (precisely the system lib) does use std:snprintf which is overwritten by the gettext header file libintl.h on mingw (maybe we can mitigate this with a different include order?)
- Internal dependencies of boost 1.69 are different and/or not correctly handled by the widelands cmake files (maybe depends on static/dynamic linking).

Until now, i've not been able to build anything on my machine with Boost 1.69 (and GCC 8), so i am back to GCC 7 + Boost 1.6x...)

[Toni Förster (stonerl)]

>Appveyor does only build x64, x86 was disabled at some point (not sure, why exactly)

I disabled the x86 builds. Because the tests were always failing:

https://ci.appveyor.com/project/widelands-dev/widelands/builds/21100888/job/2t9btrnhe4b76089?fullLog=true#L2750

[hessenfarmer (stephan-lutz)]

Yes I think my environment is dynamically linking (as appveyor does).

So to understand the issues I will try to build all four build types (release /debug, x64 / x86) with my libintl.h changes and boost 1.69 and see what happens.

I will report back

[GunChleoc (gunchleoc)]

x86 has a segfault caused by a call of boost::split. That's a problem with the libraries that we can't do anything about.

[hessenfarmer (stephan-lutz)]

Ok I did some tests yesterday with my build environment and current trunk

1. I updated MSYS2 completely including both toolchains (i686 and x64).
2. I applied the libintl.h fix to both include directories (32bit and 64bit)
3. Results were (using dynamic linking):

x86 release build --> ok and working (just started a game)
x86 debug build --> ok and working
x64 release build --> ok and working
x64 debug build --> got some weird ICU linking errors while linking widelands.exe but this may be due to an unclean build folder with some artefacts from release not overwritten removed. I started a clean build this morning, which is still running.

However it seems that with boost 1.69 the x86 builds would work. So I will try to prepare an appveyor_fix branch tonight to reenable x86 builds.

one thing I noticed is that cmake throws some warnings about potentially broken boost dependencies but that had no effect on the build.

[hessenfarmer (stephan-lutz)]

until now my branch is doing fine for x64 and failing for x86 due to missing dll (Exit code 0x0000139).
As I managed to compile it locally and I probably used glew for this (I am not sure if I used Glew or glbinding) I suspect the same issues for the x86 build as we had with the x64 build some time ago.
I will try tonight if it compiles with glbinding locally or if I get the same error.

[Toni Förster (stonerl)]

@hessenfarmer here is the patchfile.

[hessenfarmer (stephan-lutz)]

thanks for the patch
but there are other changes included together with the change I applied. What is the purpose of this changes?

[Toni Förster (stonerl)]

I used the libintl.h that is installed on my system as basefile and diffed it against yours.

[Toni Förster (stonerl)]

What were your changes?

[hessenfarmer (stephan-lutz)]

just one change in line 369.
thanks anyway for the explanation how to do this.
One last question is the patch command working as well in a windows batch world?

[hessenfarmer (stephan-lutz)]

Personally I can't see any difference in applying a patch and overwriting the file with a modified version. This will break in either way as soon as the original libintl.h will change

[Toni Förster (stonerl)]

> One last question is the patch command working
> as well in a windows batch world?

I do think so, don't have a windows system on hand.

> Personally I can't see any difference in applying
> a patch and overwriting the file with a modified
> version. This will break in either way as soon as
> the original libintl.h will change

With the patch you see what the changes are. When you apply an entire file, it is hard to spot the difference/changes you made.

[hessenfarmer (stephan-lutz)]

> With the patch you see what the changes are. When you apply an entire file, it is hard to spot > the difference/changes you made.

that is a good reason. So I will try to get this working with a patch file

[hessenfarmer (stephan-lutz)]

ok I can confirm that glbinding is the culprit for broken x86 builds will change my branch to use glew for x86 as long as this takes to be fixed.
@ Tino could you address this issue again in Alex Mingw repo?

[hessenfarmer (stephan-lutz)]

as the fix is basically working I now uploaded a branch with a patchfile instead of the copy

[hessenfarmer (stephan-lutz)]

shall we close this bug as the fix branch is merged or shall we keep it open for b21 to revert the changes made in the branch

[hessenfarmer (stephan-lutz)]

Ok as we have a fix for b20 which is merged to trunk, but not really fixed the underlying cause. I have postponed the bug to b21 to be finally fixed. Although it might be more likely that a nother problem arises with appveyor and boost.

[GunChleoc (gunchleoc)]

Fixed in build20-rc1