Facing issues while compiling "v3.6.9-dbaas-testing" branch

Other MongoDB Topics MongoDB Server Development
1

Hi Team, I am trying to compile v3.6.9-dbaas-testing branch as I want 3.6.9 version for my product on Centos7. I am following Build MongoDB From Source · mongodb/mongo Wiki · GitHub page for the prerequisites and steps.
I am facing a problem where one time the compilation stops giving below error. However, if I try to compile same binary manually, it gets created without any error. PFA.

image
image3360×1868 1.72 MB

--------------Some env info-------------
[root@lab mongo]# uname -a Linux lab 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

image
image3358×896 1.03 MB

Could you please help me with resolving this?

2

Hi Harpinder,

Is there a reason you need to build from source? CentOS 7 is a supported platform for binary packages: Install MongoDB Community Edition on Red Hat or CentOS. I would recommend installing the latest version of the 3.6 production release series (currently 3.6.17) so you have the latest bug fixes and stability improvements. Minor releases do not include any backward-breaking changes, and there have been many improvements since MongoDB 3.6.9 was released in Nov, 2018.

If you definitely want to build from source, the v3.6.9-dbaas-testing branch isn’t what you are looking for (it’s a testing branch). Releases are tagged, so you want to use the v3.6.9 tag: Release r3.6.9 · mongodb/mongo · GitHub.

Regards,
Stennie

3

Thanks for the quick response, I’ll try the v3.6.9 tag and see if I face the same issue again.

4

Hi Team, I am now building code from v3.6.9 tag.

Problem::
The same issue as before:

image
image3354×1522 1.21 MB

I had to do below changes for resolving other issues faced while compilation:

  • I had to include dummy version.json file, kept at root of code directory with below content as compilation was halting due to version not getting derived. Followed https://jira.mongodb.org/browse/SERVER-21317 for the workaround

  • As per Mongo Ticket SERVER-36206, included --disable-warnings-as-errors flag

  • Per Mongo Ticket SERVER-31439, added os.environ in PATH in SConstruct file

Please let me know how can I have smooth compilation?

5

Hi, I have several comments here.

  • First, please don’t use screenshots to post errors. It makes it much harder to, for instance, comment on a specific line of output.

  • Second, would you please clarify why you are building the now quite old 3.6 release, rather than a more modern branch like v4.2? And, if there is a specific reason for building a v3.6 series release, why are you building the .9 version, rather than v3.6.17, which is the latest bugfix release in the v3.6 series? You definitely want to be running the newest bugfix release out of any branch.

  • Third, there are several pieces of information that will be required to make forward progress here. At minimum, please tell us your operating system distro and version, the version of GCC that you are using, how you obtained the source code (e.g. git checkout, tarball from the downloads site, something else), any local edits to the source code, and the complete SCons invocation that you used to try and build.

  • Fourth, the error shown in the screenshot is what I would expect to see if the build was cancelled with ^C or similar. No compiler or linker error has been shown. Is it possible that something else on the machine is interfering with the build? Could you be running out of memory or some other resource?

I also have some comments on the various tickets you mentioned.

  • https://jira.mongodb.org/browse/SERVER-21317 is fixed in v3.6.9, so you should not need to include a dummy version.json file. What error did you observe when you didn’t provide the version.json file? Note that you can also explicitly set a version by adding MONGO_VERSION=x.y.z on the command line. However, this should not generally be necessary.

  • It is fine to use --disable-warnings-as-errors if you are using a newer compiler than the official compiler version. On MongoDB v3.6, that is GCC 5.4. Note though that we do no in house builds or tests of the v3.6 branch with newer compilers, and we don’t guarantee that builds using other compilers will work. If it is possible for you to build with GCC 5, that would be preferred to using a newer compiler.

  • The issue the user faced in SERVER-31439 was likely a broken local toolchain. SCons intentionally does not propagate the users shell PATH into the build, because it makes the build non-deterministic. If your g++ binary isn’t able to locate the linker it was configured to use without setting PATH, then the toolchain installation is likely broken.

I think if you can follow up on each of the points above, we can get things set up so that you have a working build without needing to work around any particular issues.

Thanks,
Andrew

2 Likes
6

Noted, thanks for the feedback

As per the product specifications I have to specifically work for MongoDB 3.6.9 version and there is no plan for updates in near future so I’ll have to stick to it only.

OS Distro and Version → Centos 7
[root@portal4 mongo-r3.6.9]# uname -a Linux portal4 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

GCC Version
gcc (GCC) 5.4.0
Followed https://community.webfaction.com/questions/20158/installing-gcc-54 link to install gcc 5.4.0 version.
Python version
[root@portal4 mongo-r3.6.9]# python --version Python 2.7.5
Clang version
[root@portal4 mongo-r3.6.9]# clang --version
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
SCons version
[root@portal4 mongo-r3.6.9]# scons --version
SCons by Steven Knight et al.:
script: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
engine: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
engine path: ['/usr/lib/scons/SCons']
Copyright (c) 2001 - 2019 The SCons Foundation

how you obtained the source code
Downloaded from below link

any local edits to the source code

python buildscripts/scons.py all --variables-files=etc/scons/propagate_shell_environment.vars --disable-warnings-as-errors

Not sure, no other process was running on machine while compiling the code. The VM was dedicated for compilation purpose only
[root@portal4 mongo-r3.6.9]# free -m
total used free shared buff/cache available
Mem: 11853 624 524 8 10704 11094
Swap: 4095 0 4095

This was the error:
[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py all --disable-warnings-as-errors
scons: Reading SConscript files ...
Invalid MONGO_VERSION '', or could not derive from version.json or git metadata. Please add a conforming MONGO_VERSION=x.y.z[-extra] as an argument to SCons
[root@portal4 mongo-r3.6.9]#
[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py all
scons: Reading SConscript files ...
Invalid MONGO_VERSION '', or could not derive from version.json or git metadata. Please add a conforming MONGO_VERSION=x.y.z[-extra] as an argument to SCons

I had tried below command which resulted in unknown variable message MONGO_GITHASH but instead of removing MONGO_GITHASH from command line I added version.json
[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py MONGO_VERSION=3.6.9 MONGO_GITHASH=none all
scons: Reading SConscript files ...
Mkdir("build/scons")
scons version: 2.5.0
python version: 2 7 5 'final' 0
Unknown variables specified: MONGO_GITHASH

Also git describe was not going to return any output as I had downloaded the code instead of cloning it. So opted for version.json workaround.

If I don’t add PATH in SConstruct file I get below error:
[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py all
scons: Reading SConscript files ...
scons version: 2.5.0
python version: 2 7 5 'final' 0
Checking whether the C compiler works... yes
Checking whether the C++ compiler works... yes
Checking that the C++ compiler can link a C++ program... yes
Checking if C++ compiler "g++" is GCC... yes
Checking if C compiler "gcc" is GCC... yes
Detected a x86_64 processor
Checking if target OS linux is supported by the toolchain... yes
Checking if C compiler is GCC 5.3.0 or newer...no
Checking if C++ compiler is GCC 5.3.0 or newer...no
ERROR: Refusing to build with compiler that does not meet requirements
See /root/mongoCompilation_TagCode/mongo-r3.6.9/build/scons/config.log for details
So i had to include the PATH variable to SConstruct file

I hope I have answered the required questions, let me know if you need further information.
Thanks in advance!

7

As per the product specifications I have to specifically work for MongoDB 3.6.9 version and there is no plan for updates in near future so I’ll have to stick to it only.

There is no good reason for a specification to demand a version of MongoDB with any more specificity than major.minor version, which is what describes the feature set. So, it would be reasonable for a product specification to say it required MongoDB v3.6, or v4.2, or similar. But specifying the patch level simply means that the resulting product will be forever ineligible for bugfixes to the database layer, which can’t be what was intended. You should endeavor to get this restriction lifted so you can use v.3.6.17 or newer. Or, please let us know what is so special about v3.6.9 that you can’t use a newer v3.6 version. Is there a bug in v3.6 versions newer than v3.6.9 that has not yet been fixed on the v3.6 branch? If so, we would want to know so we could address it. More information here will be very helpful.

OS Distro and Version → Centos 7
[root@portal4 mongo-r3.6.9]# uname -a Linux portal4 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

GCC Version
gcc (GCC) 5.4.0
Followed https://community.webfaction.com/questions/20158/installing-gcc-54 link to install gcc 5.4.0 version.
Python version
[root@portal4 mongo-r3.6.9]# python --version Python 2.7.5
Clang version
[root@portal4 mongo-r3.6.9]# clang --version
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
SCons version
[root@portal4 mongo-r3.6.9]# scons --version
SCons by Steven Knight et al.:
script: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
engine: v3.1.2.bee7caf9defd6e108fc2998a2520ddb36a967691, 2019-12-17 02:07:09, by bdeegan on octodog
engine path: ['/usr/lib/scons/SCons']
Copyright (c) 2001 - 2019 The SCons Foundation

This all looks fine. Note that the system SCons version is irrelevant, since the MongoDB source tree contains its own copy of SCons, used by buildscripts/scons.py.

how you obtained the source code
Downloaded from below link

Fine, but see my notes below. You will have an easier time if you download instead from the download center.

any local edits to the source code

[quote=“Harpinder_Kaur, post:4, topic:2701”]

  • I had to include dummy version.json file, kept at root of code directory with below content as compilation was halting due to version not getting derived. Followed SERVER-21317 for the workaround

More on this below.

  • As per Mongo Ticket SERVER-36206 , included --disable-warnings-as-errors flag

This shouldn’t be necessary if you are building with GCC 5.4 as you indicate. What happens if you don’t use it?

  • Per Mongo Ticket SERVER-31439 , added os.environ in PATH in SConstruct file
    [/quote]

This also shouldn’t be necessary, especially since you are using --variables-files=…/propagate_shell_environment.vars, which does this for you. I suggest backing this change out, as it will make your build nondeterministic.

python buildscripts/scons.py all --variables-files=etc/scons/propagate_shell_environment.vars --disable-warnings-as-errors

With a properly configured GCC 5.4 installation, neither of these flags should be required. Also, I don’t see where you are specifying that you want to use your GCC 5.4 installation. I’d expect to see something like CC=gcc-5.4 CXX=g+±5.4 here. Where did you install GCC-5.4 and what are the paths to the GCC 5.4 gcc and g++ binaries?

Not sure, no other process was running on machine while compiling the code. The VM was dedicated for compilation purpose only
[root@portal4 mongo-r3.6.9]# free -m
total used free shared buff/cache available
Mem: 11853 624 524 8 10704 11094
Swap: 4095 0 4095

This was the error:
[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py all --disable-warnings-as-errors
scons: Reading SConscript files ...
Invalid MONGO_VERSION '', or could not derive from version.json or git metadata. Please add a conforming MONGO_VERSION=x.y.z[-extra] as an argument to SCons
[root@portal4 mongo-r3.6.9]#
[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py all
scons: Reading SConscript files ...
Invalid MONGO_VERSION '', or could not derive from version.json or git metadata. Please add a conforming MONGO_VERSION=x.y.z[-extra] as an argument to SCons

I had tried below command which resulted in unknown variable message MONGO_GITHASH but instead of removing MONGO_GITHASH from command line I added version.json
[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py MONGO_VERSION=3.6.9 MONGO_GITHASH=none all
scons: Reading SConscript files ...
Mkdir("build/scons")
scons version: 2.5.0
python version: 2 7 5 'final' 0
Unknown variables specified: MONGO_GITHASH

This was my mistake - the variable is called MONGO_GIT_HASH (note the extra _).

Also git describe was not going to return any output as I had downloaded the code instead of cloning it. So opted for version.json workaround.

The problem is that the github based archives don’t contain the version metadata, which is why you need to mess around with MONGO_VERSION and MONGO_GIT_HASH to make this work. However, the source downloads from the mongodb download site do contain the data already. Please try downloading the source from Download MongoDB Community Server | MongoDB instead. That will contain a pre-populated version.json.

Alternatively, use MONGO_GIT_HASH, and it won’t try to call git describe.

If I don’t add PATH in SConstruct file I get below error:
[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py all
scons: Reading SConscript files ...
scons version: 2.5.0
python version: 2 7 5 'final' 0
Checking whether the C compiler works... yes
Checking whether the C++ compiler works... yes
Checking that the C++ compiler can link a C++ program... yes
Checking if C++ compiler "g++" is GCC... yes
Checking if C compiler "gcc" is GCC... yes
Detected a x86_64 processor
Checking if target OS linux is supported by the toolchain... yes
Checking if C compiler is GCC 5.3.0 or newer...no
Checking if C++ compiler is GCC 5.3.0 or newer...no
ERROR: Refusing to build with compiler that does not meet requirements
See /root/mongoCompilation_TagCode/mongo-r3.6.9/build/scons/config.log for details

Please post the contents of the config.log. Anytime you get this message, you should post the contents of config.log.

8

The same one mentioned in SERVER-36206’s description related to ScopeGuardImpl1 and other functions

Now started fresh compilation with below command as per your suggestion:
python buildscripts/scons.py MONGO_VERSION=3.6.9 --variables-files=etc/scons/propagate_shell_environment.vars all

GCC is installed in $HOME/gcc/bin/gcc as per https://community.webfaction.com/questions/20158/installing-gcc-54

file /root/mongoCompilation_TagCode/mongo-r3.6.9/SConstruct,line 1083:
Configure(confdir = build/scons/opt/sconf_temp)
scons: Configure: Checking whether the C compiler works...
scons: Configure: "build/scons/opt/sconf_temp/conftest_0.c" is up to date.
scons: Configure: The original builder output was:
|build/scons/opt/sconf_temp/conftest_0.c <-
| |
| |int main()
| |{
| | return 0;
| |}
| |
|
gcc -o build/scons/opt/sconf_temp/conftest_0.o -c build/scons/opt/sconf_temp/conftest_0.c
scons: Configure: yes
`scons: Configure: Checking whether the C++ compiler works... ` `scons: Configure: "build/scons/opt/sconf_temp/conftest_1.cpp" is up to date.` `scons: Configure: The original builder output was:` ` |build/scons/opt/sconf_temp/conftest_1.cpp <-` ` | |` ` | |int main()` ` | |{` ` | | return 0;` ` | |}` ` | |` ` |` `g++ -o build/scons/opt/sconf_temp/conftest_1.o -c build/scons/opt/sconf_temp/conftest_1.cpp` `scons: Configure: yes`
scons: Configure: Checking that the C++ compiler can link a C++ program...
scons: Configure: "build/scons/opt/sconf_temp/conftest_2.cpp" is up to date.
scons: Configure: The original builder output was:
|build/scons/opt/sconf_temp/conftest_2.cpp <-
| |
| |#include <iostream>
| |#include <cstdlib>
| |
| |int main() {
| | std::cout << "Hello, World" << std::endl;
| | return EXIT_SUCCESS;
| |}
| |
|
g++ -o build/scons/opt/sconf_temp/conftest_2.o -c build/scons/opt/sconf_temp/conftest_2.cpp
g++ -o build/scons/opt/sconf_temp/conftest_2 build/scons/opt/sconf_temp/conftest_2.o
scons: Configure: yes
`scons: Configure: Checking if C++ compiler "g++" is GCC... ` `scons: Configure: "build/scons/opt/sconf_temp/conftest_3.cpp" is up to date.` `scons: Configure: The original builder output was:` ` |build/scons/opt/sconf_temp/conftest_3.cpp <-` ` | |` ` | |#if defined(__GNUC__) && !defined(__clang__)` ` | |/* we are using toolchain defined(__GNUC__) && !defined(__clang__) */` ` | |#else` ` | |#error` ` | |#endif` ` | |` ` |` `g++ -o build/scons/opt/sconf_temp/conftest_3.o -c build/scons/opt/sconf_temp/conftest_3.cpp` `scons: Configure: yes`
scons: Configure: Checking if C compiler "gcc" is GCC...
scons: Configure: "build/scons/opt/sconf_temp/conftest_4.c" is up to date.
scons: Configure: The original builder output was:
|build/scons/opt/sconf_temp/conftest_4.c <-
| |
| |#if defined(__GNUC__) && !defined(__clang__)
| |/* we are using toolchain defined(__GNUC__) && !defined(__clang__) */
| |#else
| |#error
| |#endif
| |
|
gcc -o build/scons/opt/sconf_temp/conftest_4.o -c build/scons/opt/sconf_temp/conftest_4.c
scons: Configure: yes
`scons: Configure: "build/scons/opt/sconf_temp/conftest_5.c" is up to date.` `scons: Configure: The original builder output was:` ` |build/scons/opt/sconf_temp/conftest_5.c <-` ` | |` ` | |#if defined(__x86_64) || defined(_M_AMD64)` ` | |/* Detected x86_64 */` ` | |#else` ` | |#error not x86_64` ` | |#endif` ` | |` ` |` `gcc -o build/scons/opt/sconf_temp/conftest_5.o -c build/scons/opt/sconf_temp/conftest_5.c` `scons: Configure: Detected a x86_64 processor`
scons: Configure: Checking if target OS linux is supported by the toolchain...
scons: Configure: "build/scons/opt/sconf_temp/conftest_6.c" is up to date.
scons: Configure: The original builder output was:
|build/scons/opt/sconf_temp/conftest_6.c <-
| |
| |#if defined(__APPLE__)
| |#include <TargetConditionals.h>
| |#endif
| |#if defined(__linux__)
| |/* detected linux */
| |#else
| |#error
| |#endif
| |
|
gcc -o build/scons/opt/sconf_temp/conftest_6.o -c build/scons/opt/sconf_temp/conftest_6.c
scons: Configure: yes

file /root/mongoCompilation_TagCode/mongo-r3.6.9/SConstruct,line 1824:
Configure(confdir = build/scons/opt/sconf_temp)
scons: Configure: Checking if C compiler is GCC 5.3.0 or newer...
scons: Configure: "build/scons/opt/sconf_temp/conftest_7.c" is up to date.
scons: Configure: The original builder output was:
|build/scons/opt/sconf_temp/conftest_7.c <-
| |
| |#if !defined(__GNUC__) || defined(__clang__)
| |#error
| |#endif
| |
| |#if (__GNUC__ < 5) || (__GNUC__ == 5 && __GNUC_MINOR__ < 3) || (__GNUC__ == 5 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ < 0)
| |#error GCC 5.3.0 or newer is required to build MongoDB
| |#endif
| |
| |int main(int argc, char* argv[]) {
| | return 0;
| |}
| |
|
Compiling build/scons/opt/sconf_temp/conftest_7.o
build/scons/opt/sconf_temp/conftest_7.c:7:2: error: #error GCC 5.3.0 or newer is required to build MongoDB
#error GCC 5.3.0 or newer is required to build MongoDB
^
scons: Configure: no
``
scons: Configure: Checking if C++ compiler is GCC 5.3.0 or newer...
scons: Configure: "build/scons/opt/sconf_temp/conftest_8.cpp" is up to date.
scons: Configure: The original builder output was:
|build/scons/opt/sconf_temp/conftest_8.cpp <-
| |
| |#if !defined(__GNUC__) || defined(__clang__)
| |#error
| |#endif
| |
| |#if (__GNUC__ < 5) || (__GNUC__ == 5 && __GNUC_MINOR__ < 3) || (__GNUC__ == 5 && __GNUC_MINOR__ == 3 && __GNUC_PATCHLEVEL__ < 0)
| |#error GCC 5.3.0 or newer is required to build MongoDB
| |#endif
| |
| |int main(int argc, char* argv[]) {
| | return 0;
| |}
| |
|
Compiling build/scons/opt/sconf_temp/conftest_8.o
build/scons/opt/sconf_temp/conftest_8.cpp:7:2: error: #error GCC 5.3.0 or newer is required to build MongoDB
#error GCC 5.3.0 or newer is required to build MongoDB
^
scons: Configure: no

9

Also now after compiling tag 3.6.9 code, there are only few shared objects listed for binaries. However, the actual product binary has many more additional shared objects. Would you help me understand how can I get the same list of shared objects/shared libraries in my binaries too…what all changes should be done or is it fine if we want to add different shared objects to our binaries?

ldd output for binaries created from code for 3.6.9 tag
mongo:
linux-vdso.so.1 => (0x00007ffd8fdab000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f12b6bf0000)
librt.so.1 => /lib64/librt.so.1 (0x00007f12b69e8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f12b67e4000)
libstdc++.so.6 => /root/gcc/lib/libstdc++.so.6 (0x00007f12b646a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f12b6168000)
libgcc_s.so.1 => /root/gcc/lib/libgcc_s.so.1 (0x00007f12b5f51000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f12b5d35000)
libc.so.6 => /lib64/libc.so.6 (0x00007f12b5968000)
/lib64/ld-linux-x86-64.so.2 (0x00007f12b87db000)
mongobridge:
linux-vdso.so.1 => (0x00007ffc89bf9000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc0c9d47000)
librt.so.1 => /lib64/librt.so.1 (0x00007fc0c9b3f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc0c993b000)
libstdc++.so.6 => /root/gcc/lib/libstdc++.so.6 (0x00007fc0c95c1000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc0c92bf000)
libgcc_s.so.1 => /root/gcc/lib/libgcc_s.so.1 (0x00007fc0c90a8000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc0c8e8c000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc0c8abf000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc0cad79000)
mongod:
linux-vdso.so.1 => (0x00007ffd2a1f0000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f54cd874000)
librt.so.1 => /lib64/librt.so.1 (0x00007f54cd66c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f54cd468000)
libstdc++.so.6 => /root/gcc/lib/libstdc++.so.6 (0x00007f54cd0ee000)
libm.so.6 => /lib64/libm.so.6 (0x00007f54ccdec000)
libgcc_s.so.1 => /root/gcc/lib/libgcc_s.so.1 (0x00007f54ccbd5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f54cc9b9000)
libc.so.6 => /lib64/libc.so.6 (0x00007f54cc5ec000)
/lib64/ld-linux-x86-64.so.2 (0x00007f54d09e3000)
mongoperf:
linux-vdso.so.1 => (0x00007ffefb7a0000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f7ecb5f9000)
librt.so.1 => /lib64/librt.so.1 (0x00007f7ecb3f1000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f7ecb1ed000)
libstdc++.so.6 => /root/gcc/lib/libstdc++.so.6 (0x00007f7ecae73000)
libm.so.6 => /lib64/libm.so.6 (0x00007f7ecab71000)
libgcc_s.so.1 => /root/gcc/lib/libgcc_s.so.1 (0x00007f7eca95a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7eca73e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f7eca371000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7ece703000)
mongos:
linux-vdso.so.1 => (0x00007ffc3a9db000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007ff4a0bd3000)
librt.so.1 => /lib64/librt.so.1 (0x00007ff4a09cb000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4a07c7000)
libstdc++.so.6 => /root/gcc/lib/libstdc++.so.6 (0x00007ff4a044d000)
libm.so.6 => /lib64/libm.so.6 (0x00007ff4a014b000)
libgcc_s.so.1 => /root/gcc/lib/libgcc_s.so.1 (0x00007ff49ff34000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff49fd18000)
libc.so.6 => /lib64/libc.so.6 (0x00007ff49f94b000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff4a289a000)

**ldd output for actual mongo binaries from 3.6.9 setup **
/usr/bin/mongo:
linux-vdso.so.1 => (0x00007fff931f3000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f1d641ea000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f1d63d88000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f1d63b16000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f1d63912000)
librt.so.1 => /lib64/librt.so.1 (0x00007f1d6370a000)
libm.so.6 => /lib64/libm.so.6 (0x00007f1d63408000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f1d631f2000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1d62fd6000)
libc.so.6 => /lib64/libc.so.6 (0x00007f1d62c09000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1d65f83000)
libz.so.1 => /lib64/libz.so.1 (0x00007f1d629f3000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f1d627a6000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f1d624bd000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f1d622b9000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f1d62086000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f1d61e76000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f1d61c72000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f1d61a4b000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f1d617e9000)
/usr/bin/mongod:
linux-vdso.so.1 => (0x00007ffd64af4000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f47af003000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f47aeba1000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f47ae92f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f47ae72b000)
librt.so.1 => /lib64/librt.so.1 (0x00007f47ae523000)
libm.so.6 => /lib64/libm.so.6 (0x00007f47ae221000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f47ae00b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f47addef000)
libc.so.6 => /lib64/libc.so.6 (0x00007f47ada22000)
/lib64/ld-linux-x86-64.so.2 (0x00007f47b2328000)
libz.so.1 => /lib64/libz.so.1 (0x00007f47ad80c000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f47ad5bf000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f47ad2d6000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f47ad0d2000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f47ace9f000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f47acc8f000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f47aca8b000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f47ac864000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f47ac602000)
/usr/bin/mongoperf:
linux-vdso.so.1 => (0x00007fff219f1000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f096fd2c000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f096f8ca000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f096f658000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f096f454000)
librt.so.1 => /lib64/librt.so.1 (0x00007f096f24c000)
libm.so.6 => /lib64/libm.so.6 (0x00007f096ef4a000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f096ed34000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f096eb18000)
libc.so.6 => /lib64/libc.so.6 (0x00007f096e74b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0972fea000)
libz.so.1 => /lib64/libz.so.1 (0x00007f096e535000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f096e2e8000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f096dfff000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f096ddfb000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f096dbc8000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f096d9b8000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f096d7b4000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f096d58d000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f096d32b000)
/usr/bin/mongos:
linux-vdso.so.1 => (0x00007fff4d1d6000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f9317ac2000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f9317660000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007f93173ee000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f93171ea000)
librt.so.1 => /lib64/librt.so.1 (0x00007f9316fe2000)
libm.so.6 => /lib64/libm.so.6 (0x00007f9316ce0000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f9316aca000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f93168ae000)
libc.so.6 => /lib64/libc.so.6 (0x00007f93164e1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f931994b000)
libz.so.1 => /lib64/libz.so.1 (0x00007f93162cb000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f931607e000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f9315d95000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f9315b91000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f931595e000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f931574e000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f931554a000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f9315323000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f93150c1000)

10

The same one mentioned in SERVER-36206’s description related to ScopeGuardImpl1 and other functions

I didn’t mean not to use GCC 5.4. I meant that you shoould not need --disable-warnings-as-errors if you are actually using GCC 5.4, as you suggest you are.

Now started fresh compilation with below command as per your suggestion:
python buildscripts/scons.py MONGO_VERSION=3.6.9 --variables-files=etc/scons/propagate_shell_environment.vars all

But you are still using --variables-files=etc/scons/propagate_shell_environment.vars. That is the part I’m saying you should remove.

GCC is installed in $HOME/gcc/bin/gcc as per https://community.webfaction.com/questions/20158/installing-gcc-54

In that case, you need to tell the build to use that compiler. So you should be saying something like:

python buildscripts/scons.py MONGO_VERSION=3.6.9 MONGO_GIT_HASH=unknown CC=$HOME/gcc/bin/gcc CXX=$HOME/gcc/bin/g++

If the above change to include the CC and CXX variables doesn’t fix it, please re-run your build adding the flags VERBOSE=1 and --config=force, and then repost your config.log.

My suspicion this entire time is that you have never actually been using your installed GCC 5.4.

11

Also now after compiling tag 3.6.9 code, there are only few shared objects listed for binaries. However, the actual product binary has many more additional shared objects. Would you help me understand how can I get the same list of shared objects/shared libraries in my binaries too…what all changes should be done or is it fine if we want to add different shared objects to our binaries?

It looks to me like you are comparing the ldd output of the community build of 3.6.9 that you made to the ldd output of the enterprise build of 3.6.9. The enterprise build includes closed source components that are not available to you. You will not be able to recreate the exact list of library dependencies in your build of the community sources, nor do you need to, since those libraries are included only to support features that are available only in the enterprise version.

12

Thanks for clearing out.

13

If I didn’t use --variables-files=etc/scons/propagate_shell_environment.vars in command line then I used to get below error:

[root@portal4 mongo-r3.6.9]# python buildscripts/scons.py all
scons: Reading SConscript files ...
scons version: 2.5.0
python version: 2 7 5 'final' 0
Checking whether the C compiler works... yes
Checking whether the C++ compiler works... yes
Checking that the C++ compiler can link a C++ program... yes
Checking if C++ compiler "g++" is GCC... yes
Checking if C compiler "gcc" is GCC... yes
Detected a x86_64 processor
Checking if target OS linux is supported by the toolchain... yes
Checking if C compiler is GCC 5.3.0 or newer...no
Checking if C++ compiler is GCC 5.3.0 or newer...no
ERROR: Refusing to build with compiler that does not meet requirements
See /root/mongoCompilation_TagCode/mongo-r3.6.9/build/scons/config.log for details

And now as per your suggestion, now started clean compilation with below command
python buildscripts/scons.py MONGO_VERSION=3.6.9 MONGO_GIT_HASH=unknown CC=$HOME/gcc/bin/gcc CXX=$HOME/gcc/bin/g++

14

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.