#2464 Build fails with Boost-1.60

[Barry Jackson]

Build fails with boost-1.60, complete log attached. This is in Mageia Linux current development branch.

In file included from /usr/include/boost/property_map/property_map.hpp:16:0,
from /usr/include/boost/graph/graphviz.hpp:19,
from ./../SDCCralloc.hpp:54,
from ralloc2.cc:24:
/usr/include/boost/graph/adjacency_matrix.hpp:446:5: error: 'ice_not' is not a member of 'boost::type_traits'
BOOST_STATIC_ASSERT(type_traits::ice_not<(is_same<directed, bidirectionals="">::value)>::value);
^</directed,>

[Philipp Klaus Krause]

This seems to be a bug in boost, and I don't think we can do anything about it:
https://svn.boost.org/trac/boost/ticket/11880
It seems this bug hit any program that uses adjacency matrices from boost.

Philipp

[Ben Shi]

Do we need to check the boost version in configure?

[Ronaldo]

There is a simple fix for this problem. I implemented it here:

https://github.com/lronaldo/cpctelera/commit/fa9d1cce58402b1e7e307f7760624351256f2f91

Boost developers have tagged part of their code as deprecated and someone has removed an #include statement in graphviz.hpp. However, graphviz.h still makes use of the definitions removed (ice.hpp). Simply including ice.hpp before including graphviz.h solves the problem.

[Philipp Klaus Krause]

1) We should keep boost 1.60 out of distros. When I see it appear in debian, I'll file a bug of sufficient priority (unless someone else does it quicker). This boost bug is a serious issue affecting many programs. Ideally, most users will never see boost 1.60.
2) If we want SDCC to compile with the broken boost version, the workaround should be conditional, e.g. depending on the value of the BOOST_VERSION macro.

Philipp

[Ronaldo]

I agree with you, Phillip. However, I think it is important to keep into account that there is no way to prevent users from having boost 1.60. Moreover, most of them have it already, as most users are developers.

I think that adding the include line I suggest with a previous check of BOOST_VERSION macro would prevent SDCC from being discarded by many developers on the event of it failing to build. Using BOOST_VERSION, SDCCralloc.hpp will look like this:

....
#include <fstream>

// PATCH for libboost 1.60
#include <boost/version.hpp>
#if BOOST_VERSION >= 106000
   #include <boost/type_traits/ice.hpp>
#endif

#include <boost/graph/graphviz.hpp>
....

[Philipp Klaus Krause]

I applied a workaround in revision [r9498], testing via == instead of >=, since I assume that 1) boost will fix their bug, 2) the workaround relies on deprecated boost features resulting in warnings (and possibly failures in the future).

Philipp

P.S.: I did not test with boost 1.60, I just checked that SDCC still compiles with boost 1.58.

[Barry Jackson]

I applied Ronaldo's original workaround as a patch and it now builds fine against boost-1.60 for Mageia 6 (next release).
Thanks for this, we can now keep sdcc in the distro :)

[Maarten Brock]

That seems like a peculiar decision. Instead of dropping boost-1.60 from your Mageia release in favor of a less broken version or fixing boost-1.60, you considered dropping sdcc and now settle for a patch in sdcc to work around the bug in boost.

[Ronaldo]

Well, the bug is not particular for Mageia. I wrote the first version of the workaround because I stomped into the same problem in Arch. Many developers use up-to-date Linux distributions with boost 1.60. The options are adding this simple workaround or waiting for boost developers to fix the bug. The second option has the disadvantage of bothering many SDCC present and future users with a bug that is not SDCC's fault, and that we don't know when it will be fixed. I personally prefer saving users the pain of having to workaround the bug themselves, either by downgrading or by patching SDCC manually.

[Maarten Brock]

Ronaldo, I was addressing Barry not you. I agree with the work-around you proposed and as implemented by Philipp. Boost-1.60 is out there and we will have to deal with it. I disagree however with a linux distribution that considers to drop packages because they depend on a library of which the distribution chose to include a broken version. IMHO they should consider to revert the library.

[Ronaldo]

No worries :). I also agree with you. Probably, people managing different distributions are still unaware of the problem.

[Barry Jackson]

However using the full conditional patch I get:
In file included from ralloc2.cc:24:0:
./../SDCCralloc.hpp:55:25: fatal error: boost/version: No such file or directory
compilation terminated.

[Ronaldo]

Sorry, I introduced a typo when copying the code to the forum. Include should be

#include <boost/version.hpp>

I've edited my post to prevent others from copying the typo. I accidentally removed .hpp.

[Barry Jackson]

Yes that's better, thanks.

[Maarten Brock]

Can't this bug report be closed?

[Ben Shi]

I thought it can be closed，since it was not our fault and we could do no more.

[Philipp Klaus Krause]

What if boost releaases 1.61 without fixing the bug? In that case we'd have to adjust ur workaround. Should we keep this item open just in case, and only close it once we have a final fix? Or should we close it, and open another bug report if 1.61 is still broken?

Philipp

P.S.: On the boost side, this issue is currently rated priority "problem". There are currently 2237 open bug reports of that severity for boost.

[Maarten Brock]

If this isn't fixed in 1.61 we'll have to deal with it at that time. I assume there will never be a fixed 1.60 so the work-around should stay until SDCC no longer needs it. Is it your intention to adapt sdcc to no longer use the deprecated functionality? And will this problem disappear with this adaptation? If so, keep the bug open. If not, I think it can be closed.

[Philipp Klaus Krause]

We do not directly use deprecated functionality. Apparently, the graphviz writer in boost (which we use for debug output for --dump-graphs), currently uses another, deprecated part of boost.

Philipp