src/mongo/db/auth/role_graph_builtin_roles.cpp: In function ‘mongo::Status mongo::{anonymous}::_mongoInitializerFunction_AuthorizationBuiltinRoles(mongo::InitializerContext*)’:
src/mongo/db/auth/role_graph_builtin_roles.cpp:182:24: error: ‘getDefaultRWConcern’ is not a member of ‘mongo::ActionType’
<< ActionType::getDefaultRWConcern // clusterManager gets this also
^~~~~~~~~~~~~~~~~~~
src/mongo/db/auth/role_graph_builtin_roles.cpp:247:24: error: ‘getDefaultRWConcern’ is not a member of ‘mongo::ActionType’
<< ActionType::getDefaultRWConcern // clusterMonitor gets this also
^~~~~~~~~~~~~~~~~~~
src/mongo/db/auth/role_graph_builtin_roles.cpp:248:24: error: ‘setDefaultRWConcern’ is not a member of ‘mongo::ActionType’
<< ActionType::setDefaultRWConcern
^~~~~~~~~~~~~~~~~~~
src/mongo/db/auth/role_graph_builtin_roles.cpp:258:24: error: ‘refineCollectionShardKey’ is not a member of ‘mongo::ActionType’
<< ActionType::refineCollectionShardKey;
^~~~~~~~~~~~~~~~~~~~~~~~
src/mongo/db/auth/role_graph_builtin_roles.cpp: In function ‘void mongo::{anonymous}::addEnableShardingPrivileges(mongo::PrivilegeVector*)’:
src/mongo/db/auth/role_graph_builtin_roles.cpp:311:49: error: ‘refineCollectionShardKey’ is not a member of ‘mongo::ActionType’
enableShardingActions.addAction(ActionType::refineCollectionShardKey);
^~~~~~~~~~~~~~~~~~~~~~~~
Compiling build/opt/mongo/s/client/parallel.o"
It seems like scons is not able to generate the actionType’s source file, what should I do?
What is the commit hash on the v4.4 branch against which you are working?
Does the branch build for you at that commit if you don’t apply your modifications?
Have you tried building from clean (basically, remove the build directory and re-run)? Can you try that in both the unmodified v4.4 state and with your changes?
Thank you for your response.
Currently I’m trying to build branch v4.4, without my changes, from commit 7aa1b65641938719accd595bda3e45e97dc5f475.
The clean start did actually work, as the errors no longer show, however I’m now experiencing a new error (which also I’ve never encountered in branch v4.2):
…
Linking build/opt/mongo/mongod
/usr/bin/ld.gold: out of memory
collect2: error: ld returned 1 exit status
scons: *** [build/opt/mongo/mongod] Error 1
scons: building terminated because of errors.
build/opt/mongo/mongod failed: Error 1
I monitored the RAM usage throughout the compilation process, and I always have around 6-10GB of free memory. Do you have any idea?
No, sorry. No specific ideas. The server build is very resource intensive. For development purposes on v4.4 you could try building with --link-model=dynamic which definitely will reduce your memory needs. However, the binaries you produce are not production quality. You may just need to find a bigger machine (AWS?) if you plan to produce static production quality binaries.
Your parameter did the trick, however I’m using a lab server shared between several people, so it might be the case that it was previously heavy loaded, thus the out of memory error; I’ll have to look into it. Anyway, I would like to measure latencies and gather some real-world results with this build, is it “good enough”?
I wouldn’t recommend it. There is a currently unquantified performance cost for dynamic build, and we only use it for correctness builds, never performance.
Thanks for your help!
Regardless, I’ve never encountered this memory error on v4.2, I’ll also try to give a look at the build process to see if something changed
Many things changed between 4.2 and 4.4, both in the build system and the codebase. Also, the v4.4 codebase is almost certainly just bigger than v4.2 was.
tracked down this problem to the use of the gold linker (-fuse-gold). Removing this flag from the scripts, and/or replacing with -fuse-lld, it links successfully (mongod v4.4, Ubuntu 18.04.3 LTS).
with the regular build process, the gold linker fails systematically on a 128GB RAM server (but memory is NOT the problem, the ld process grows to use a minimum amount of RAM before failing with OoO)