Bug 207982
| Summary: | dns/bundy build fails with boost 1.60 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Don Lewis <truckman> | ||||
| Component: | Individual Port(s) | Assignee: | Mathieu Arnold <mat> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | w.schwarzenfeld | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(mat) |
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| URL: | https://github.com/bundy-dns/bundy/issues/102 | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 199601 | ||||||
| Attachments: |
|
||||||
Well, really I don't have any idea of what you are talking about, I assume it's going to be broken soon(tm) ? If regenerating them with the newer boost still works with the older, we could go this way. On the other hand, I think the best bet is to go open a ticket on the bundy bug tracker, https://github.com/bundy-dns/bundy/issues I suspect that the new versions of these files won't work with older boost. Opening an upstream ticket is probably the best way to go. Upstream ticket: <https://github.com/bundy-dns/bundy/issues/102> I have other errors:
session.cc:180:44: error: no member named 'io_service' in 'asio::basic_stream_socket<asio::local::stream_protocol, asio::stream_socket_service<asio::local::stream_protocol> >'
asio::deadline_timer timer(socket_.io_service());
After solved this, with replace all (4 times) .io_service with .get_io_service:
in /usr/ports/dns/bundy/work/bundy-d310c5d/src/lib/cc/session.cc
make[8]: stopped in /usr/ports/dns/bundy/work/bundy-d310c5d/src/lib/asiodns
--- libbundy_asiodns_la-udp_server.lo ---
udp_server.cc:217:45: error: no type named 'value_type' in 'asio::error_code'
const asio::error_code::value_type err_val = ec.value();
~~~~~~~~~~~~~~~~~~^
Also, don't let bundy keep you from upgrading boost, you can mark it broken if needed and continue on your merry way :-) Since bundy doesn't link to any of the boost libraries and boost is only a BUILD_DEPENDS, one strategy for surviving the boost upgrade would be to add boost_1_55_0.tar.bz2 to DISTFILES and unpack it locally for the build. Point the bundy build to that location to pick up the boost headers and you should be good to go. Created attachment 168604 [details]
patch to fix dns/bundy build after boost is upgraded to 1.60
This patch can probably use some polish, but with it I can successfully build bundy after the boost port has been upgraded to 1.60.
changed it a bit, but the idea is the same. A commit references this bug: Author: mat Date: Mon Apr 18 14:29:50 UTC 2016 New revision: 413583 URL: https://svnweb.freebsd.org/changeset/ports/413583 Log: Don't depend on boost any more, we just need some headers, and stick to boost 1.55. PR: 207982 Submitted by: truckman Sponsored by: Absolight Changes: head/dns/bundy/Makefile head/dns/bundy/distinfo |
Building bundy with boost 1.60 fails with these errors: In file included from encode/base_n.cc:15: ../../../src/lib/util/encode/base32hex_from_binary.h:90:49: error: expected ')' base32hex_from_binary(BOOST_PFTO_WRAPPER(T) start) : ^ ../../../src/lib/util/encode/base32hex_from_binary.h:90:26: note: to match this '(' base32hex_from_binary(BOOST_PFTO_WRAPPER(T) start) : ^ ../../../src/lib/util/encode/base32hex_from_binary.h:92:57: error: use of undeclared identifier 'start' Base(BOOST_MAKE_PFTO_WRAPPER(static_cast<T>(start))), ^ ../../../src/lib/util/encode/base32hex_from_binary.h:90:56: error: only constructors take base initializers base32hex_from_binary(BOOST_PFTO_WRAPPER(T) start) : ^ In file included from encode/base_n.cc:16: ../../../src/lib/util/encode/binary_from_base32hex.h:99:50: error: expected ')' binary_from_base32hex(BOOST_PFTO_WRAPPER(T) start) : ^ ../../../src/lib/util/encode/binary_from_base32hex.h:99:26: note: to match this '(' binary_from_base32hex(BOOST_PFTO_WRAPPER(T) start) : ^ ../../../src/lib/util/encode/binary_from_base32hex.h:101:57: error: use of undeclared identifier 'start' Base(BOOST_MAKE_PFTO_WRAPPER(static_cast<T>(start))), [snip] The problem is that the BOOST_PFTO_WRAPPER() macro is no longer a port of boost. The cause of the problem is that a number of the files in the encode directory are derivatives of the boost header base64_from_binary.hpp and the interface between that header and the rest of boost has changed. To fix bundy, these files will have to be regenerated from the version of base64_from_binary.hpp in boost 1.60.