Opened 7 years ago

Closed 7 years ago

#3039 closed defect (fixed)

Build fails due to BOOST_STATIC_ASSERT on Fedora 19 (GCC 4.8.1)

Reported by: muks Owned by: muks
Priority: high Milestone: Sprint-20130723
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0.71 Internal?: no


BIND 10 master branch build fails on Fedora 19 due to the use of BOOST_STATIC_ASSERT which GCC 4.8.1 has a problem with. It results in such errors: In member function ‘std::vector<unsigned char> {anonymous}::GeneralAddress::convertUint32(uint32_t)’: error: typedef ‘boost_static_assert_typedef_44’ locally defined but not used [-Werror=unused-local-typedefs]
         BOOST_STATIC_ASSERT(sizeof(uint32_t) == IPV4_SIZE);
cc1plus: all warnings being treated as errors


Change History (9)

comment:1 Changed 7 years ago by muks

It looks like this is fixed in boost 1.54, but Fedora 19 currently has 1.53:

comment:2 Changed 7 years ago by muks

  • Owner set to muks
  • Status changed from new to assigned


comment:3 Changed 7 years ago by muks

  • Owner changed from muks to UnAssigned
  • Status changed from assigned to reviewing

Up for review.

Please also check one more thing: even with the fixed offset_ptr test in configure, it doesn't seem like -Werror is used for compiling the offset_ptr test in ax_boost_for_bind10.m4.

And if it is made to, the corresponding test in (following AX_BOOST_FOR_BIND10) should also check for $werror_ok.

I wonder how all this worked before.

comment:4 Changed 7 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:5 Changed 7 years ago by vorner

  • Owner changed from vorner to muks


I can understand the purpose of the change. But, can you, please, explain the second part of this condition to me?

if test "$BOOST_STATIC_ASSERT_WOULDFAIL" = "yes" -a X"$werror_ok" = X1; then

Doesn't automake put „yes“ and „no“ values, instead of 0 and 1 for boolean values? Does the werror_ok mean that it is ok to be warning there or it is ok to use werror?

comment:6 Changed 7 years ago by muks

  • Owner changed from muks to vorner

Check in for where $werror_ok is set.. it is set to 0 or 1 by our code. It is not directly set by AC_ARG_WITH (where $withval is set to yes or no), but is derived.

$werror_ok is set to 1 or 0 depending on whether --with-werror is passed or not, and also depending on whether some other tests pass. But typically:

  • --with-werror => $werror_ok=1
  • --without-werror => $werror_ok=0

comment:7 Changed 7 years ago by vorner

  • Owner changed from vorner to muks
  • Total Hours changed from 0 to 0.71

OK. That naming is little bit confusing, but it is not problem of the current branch.

I think this can be merged.

comment:8 Changed 7 years ago by muks

ChangeLog for this ticket:

639.	[bug]		muks
	Added workaround for build failure on Fedora 19 between GCC 4.8.x
	and boost versions less than 1.54. Fedora 19 currently ships
	(Trac #3039, git 4ef6830ed357ceb859ebb3e5e821a064bd8797bb)

comment:9 Changed 7 years ago by muks

  • Resolution set to fixed
  • Status changed from reviewing to closed

Merged to master branch in commit 4ef6830ed357ceb859ebb3e5e821a064bd8797bb:

* 30e7a2c [3039] Detect build failures due to BOOST_STATIC_ASSERT during configure
* b9c5315 [3039] Fix name of test variable

Resolving as fixed. Thank you for the reviews Michal.

Note: See TracTickets for help on using tickets.