[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:
===
FreeBSD www0.lambda-cloud.net 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
===

clang -v:
===
clang version 3.8.0 (tags/RELEASE_380/final)
Target: x86_64-unknown-freebsd10.1
Thread model: posix
===


Attachments: File build.log    
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

wget https://fastdl.mongodb.org/src/mongodb-src-r3.3.10.tar.gz
tar -zxvf mongodb-src-r3.3.10.tar.gz
cd mongodb-src-r3.3.10
scons CC=clang38 CXX=clang++38 all

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:
===
Compiling build/opt/mongo/db/repl/collection_bulk_loader_impl.o
In file included from src/mongo/db/repl/storage_interface_impl.cpp:33:
In file included from src/mongo/db/repl/storage_interface_impl.h:33:
In file included from src/mongo/base/status.h:32:
In file included from /usr/include/c++/v1/string:439:
In file included from /usr/include/c++/v1/algorithm:627:
/usr/include/c++/v1/utility:284:11: error: call to implicitly-deleted copy constructor of
'std::_1::unique_ptr<mongo::repl::TaskRunner, std::_1::default_delete<mongo::repl::TaskRunner> >'
second(__p.second)
^ ~~~~~~~~~~
===



 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:

    257     // Create the runner, and schedule the collection creation.
    258     _runners.emplace_back(
    259         std::make_pair(nss, stdx::make_unique<TaskRunner>(_bulkLoaderThreads.get())));

The declaration of _runners in the associated header though, has something sort of interesting:

    129     std::vector<std::pair<const NamespaceString, std::unique_ptr<TaskRunner>>> _runners;
    130 };

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.

Generated at Thu Feb 08 04:08:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.