[CXX-880] MongoDB C++11 driver fails to build on FreeBSD Created: 30/Mar/16 Updated: 08/Jan/24 Resolved: 19/May/16 |
|
| Status: | Closed |
| Project: | C++ Driver |
| Component/s: | Portability |
| Affects Version/s: | 3.0.0 |
| Fix Version/s: | 3.0.2 |
| Type: | Bug | Priority: | Blocker - P1 |
| Reporter: | Jimmy [X] | Assignee: | Mira Carey |
| Resolution: | Done | Votes: | 1 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
The driver fails to build on FreeBSD with the following errors:
Interesting that BSON types b_symbol, b_code and b_utf8 fail nothrow requirement of the constructor. The fix I applied in this case is to rewrite "bsoncxx/types/value.cpp:32"
as
Another error relates to failure of the Clang to select and appropriate overloaded function when using chrono::count(), here's an error example for modify_collection.cpp (it fails also on collection.cpp, basically anywhere append() is called with chrono::count()):
The problem comes from the fact that libc++ <chrono> defines seconds, milliseconds etc. as:
But append() accepts int32_t, int64_t etc., and int64_t is defined in system <stdint.h> header as
So compiler fails during overload resolutio to select correct version of append(), because chrono::count() returns long long which, supposedly, can match into both append(int32_t) and append(int64_t). Also here's the include hierarchy of Clang's (libc++) <cstdint> header:
|
| Comments |
| Comment by Mira Carey [ 19/May/16 ] | |||||||||||||||
|
I've resolved this ticket as fixed (we observed the same behavior on clang 3.5.1 and the committed fix allowed that build to move forward). If there's something more that's also broken that you run into after that, feel free to reopen or file a separate ticket if it seems distinct. -Jason | |||||||||||||||
| Comment by Githook User [ 19/May/16 ] | |||||||||||||||
|
Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}Message: Some b_ types had overly binding universal forwarding ctors. We need to sfinae those out if the closes #487 | |||||||||||||||
| Comment by Mira Carey [ 19/May/16 ] | |||||||||||||||
| Comment by Jimmy [X] [ 31/Mar/16 ] | |||||||||||||||
|
Here's the results:
cmake .. -DCMAKE_BUILD_TYPE=Release -DBSONCXX_POLY_USE_MNMLSTC=ON cmake .. -DCMAKE_BUILD_TYPE=Release -DBSONCXX_POLY_USE_BOOST=ON
Unfortunately, I can't upgrade Boost right now to a more recent version. So the only way to get past the static_assert failure is to make sure BSONCXX_ENUM gets defined as:
Which means changing #if !defined(BSONCXX_POLY_USE_BOOST) to #if defined(BSONCXX_POLY_USE_BOOST) | |||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 30/Mar/16 ] | |||||||||||||||
|
Apologies, those should read like
| |||||||||||||||
| Comment by Jimmy [X] [ 30/Mar/16 ] | |||||||||||||||
|
I'm not specifying any concrete polyfill, so it uses which ever it decides (in this case it's #if !defined(BSONCXX_POLY_USE_BOOST)). Passing those defines directly to CMake doesn't work
| |||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 30/Mar/16 ] | |||||||||||||||
|
Are you trying to build the driver with the boost polyfills, as opposed to the MNMLSTC polyfills? That could be part of the difference. You should be able to make that choice at CMake time by passing -DBSONCXX_POLY_USE_MNMLSTC, -DBSONCXX_POLY_USE_STD_EXPERIMENTAL, or -DBSONCXX_POLY_USE_BOOST to CMake. I'd be interested to know which of those choices results in the static assertion firing. | |||||||||||||||
| Comment by Jimmy [X] [ 30/Mar/16 ] | |||||||||||||||
|
Thanks for the quick response. Yeah the noexcept static_assert failure is pretty strange. Could it be connected to some problems with Boost? As for the chrono, it is indeed the same issue as in | |||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 30/Mar/16 ] | |||||||||||||||
|
Thanks for the bug report. I believe the issue with std::chrono conversions was already reported in However, the failure to detect the b_ types as noexcept is puzzling and somewhat worrying. They are definitely intended to be and the design of the value class depends on it, which is why we have the static_asserts. I'm planning to issue 3.0.1 today or tomorrow, which rolls up several other important build fixes, and I don't want to delay it further, but I will make this and the chrono issue as reported here and in | |||||||||||||||
| Comment by Jimmy [X] [ 30/Mar/16 ] | |||||||||||||||
|
Couldn't find and edit button, so here's some edits: The fixes I applied where Clang fails to select correct append() because chrono::count() returns long long was to manually static_cast to int64_t all calls to count():
With these fixes driver succesfully builds. |