[SERVER-25329] FreeBSD 10.1-RELEASE build issue Created: 29/Jul/16 Updated: 14/Oct/16 Resolved: 10/Oct/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 3.3.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andrew Shevchuk | Assignee: | ADAM Martin (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
uname -a: clang -v: |
||
| Attachments: |
|
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Steps To Reproduce: | wget https://fastdl.mongodb.org/src/mongodb-src-r3.3.10.tar.gz |
| Sprint: | Repl 18 (08/05/16), Repl 2016-08-29, Repl 2016-09-19, Platforms 2016-10-10, Platforms 2016-10-31 |
| Participants: |
| Description |
|
An compiler error occurred during building MongoDB 3.3.10 under FreeBSD 10.1@amd64 with clang 3.8.0: |
| Comments |
| Comment by ADAM Martin (Inactive) [ 10/Oct/16 ] | |||||
|
The failing code in question is no longer in MongoDB, and seems to not have any issue when compiling with Clang 3.8 on FreeBSD 10.3-STABLE. (It just seems to work correctly.) Clang 3.8 can be selected by passing `CC=clang38 CXX=clang++38` to `scons` when building. GCC5x seems to fail, out of the box, but I believe this to be due to the way that GCC treats C99 bits which were brough into C++11. By passing `CCFLAGS="-D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_C99_MATH -D_GLIBCXX_USE_C99_MATH_TR1"` to scons, it builds. The GCC5 issue seems to be a frequently encountered issue on FreeBSD. This stack overflow link documents the flag options needed to deal with it: http://stackoverflow.com/questions/26832199/getting-gcc-in-c11-mode-to-work-on-freebsd Please use one of the above workarounds when trying to build on FreeBSD. | |||||
| Comment by ADAM Martin (Inactive) [ 06/Oct/16 ] | |||||
|
At present, on my MongoDB workstation (running FreeBSD 10.3), I am unable to reproduce this with clang 3.8. I will try with gcc5x soon. | |||||
| Comment by Andrew Shevchuk [ 30/Jul/16 ] | |||||
|
Thanks for the help | |||||
| Comment by Andrew Morrow (Inactive) [ 30/Jul/16 ] | |||||
|
ashevchuk - Thanks for confirming that the change fixed the issue for you. | |||||
| Comment by Andrew Shevchuk [ 30/Jul/16 ] | |||||
|
Yes, this modification has solved this issue. | |||||
| Comment by Andrew Morrow (Inactive) [ 29/Jul/16 ] | |||||
|
Thanks for the bug report. I'm a little surprised - we do build the tree with clang-3.8 on Ubuntu 16.04, though, in that case we are building against the GCC 5 libstdc++. We also build on OS X, with clang, against libc++. I also just tried a build with clang-3.7 on my Ubuntu 16.04 system, and the storage_interface_impl.cpp file at r3.3.10 compiles in that configuration as well. I can't try clang-3.8 plus libc++ on that system, since, for reasons unknown to us, the Ubuntu 16.04 maintainers shipped a clang 3.7 vintage libc++ on that platform, so clang-3.8 can't build things with libc++. Taking a look at the code, the offending line looks pretty reasonable:
The declaration of _runners in the associated header though, has something sort of interesting:
I think what may be happening here is that the 'const NamespaceString' is making the entries in the vector non-moveable, which then causes the vector to try to copy the non-copyable unique_ptr. Can you try removing that const and seeing if it fixes it for you? If so, I'm somewhat amazed that this has managed to compile everywhere for us so far, across three modern compilers and three standard libraries. |