How to specify compiler when building MongoDB 3.0

[Valentin Kuznetsov]

Hi,

how can I specify location of compiler (g++) when building MongoDB 3.0. The build system uses scons and I need to pass to it the location of own compiler since we don't use default one which comes with system and always build our own version of gcc.

Thanks,

Valentin.

[Andrew Morrow]

Hi Valentin -

You can use the --cc and --cxx SCons options to specify the path to the C and C++ compilers, respectively. Run "scons --help" in the root of the source tree for a full listing of Options, and "scons --variables-help" for a list of command line Variables (CFLAGS, etc.) that can be set on the build line. Note that Variables are arguments to SCons, not environment variables.

Thanks,

Andrew

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/67fc21ac-d843-4ef7-90fb-2ea20c00d339%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Valentin Kuznetsov]

Andrew, once I specified these options and points them to location of cc/cxx executables I'm getting another error, saying

C++ compiler /mypath/gcc/4.9.1/bin/g++ does not work

The compiler version I specified, it is 4.9.1 and I have no clue what this statement means. According to SConstruct file it exit at this block:

    conf = Configure(myenv, help=False)

    if 'CheckCXX' in dir( conf ):

        if not conf.CheckCXX():

            print("C++ compiler %s does not work" % (conf.env["CXX"]))

            Exit(1)

I have no idea what conf.CheckCXX() function is doing. Is there any way to get more verbose input?

Thanks,

Valentin.

[Andrew Morrow]

Hi Valentin -

You should be able to look at the file build/scons/config.log to see the failed configure check that is leading the build system to conclude that the compiler is not functioning correctly.

I recommend either doing a clean build or building with --config=force to ensure that your config.log file contains full compiler invocations and outputs, rather than summaries of cached configure checks.

Thanks,

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/cd5dc2c3-d07a-4c04-92fb-fc569f847a50%40googlegroups.com.

[Valentin Kuznetsov]

Andrew,

thanks to your tip I found that one of the test can't locate glib libraries. I invoke build command as following:

scons --64 --cxx=$GCC_ROOT/bin/g++ --cc=$GCC_ROOT/bin/gcc --libpath=$GCC_ROOT/lib

but it still fails:

file /build/vk/MongoDB3/mongodb-src-r3.0.0/SConstruct,line 1149:

        Configure(confdir = build/scons/sconf_temp)

scons: Configure: Checking whether the C++ compiler works...

build/scons/sconf_temp/conftest_0.cpp <-

  |

  |int main()

  |{

  |    return 0;

  |}

  |

/build/vk/MongoDB3/external/gcc/4.9.1-cms/bin/g++ -o build/scons/sconf_temp/conftest_0.o -c -Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -pipe -Werror -O3 -DBOOST_ALL_NO_LIB -D_SCONS -DMONGO_EXPOSE_MACROS -DSUPPORT_UTF8 -DMONGO_OPTIMIZED_BUILD -DMONGO_BYTE_ORDER=1234 -D_FILE_OFFSET_BITS=64 build/scons/sconf_temp/conftest_0.cpp

/build/vk/MongoDB3/external/gcc/4.9.1-cms/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.9.1/cc1plus: error while loading shared libraries: libcloog-isl.so.4: cannot open shared object file: No such file or directory

scons: Configure: no

The libcloog-isl library is in my $GCC_ROOT/lib, so it is there, but scons apparently can't pick it up.

How should I fix that, i.e. how can I instruct scons to add -L/path to its tests?

Thanks,

Valentin.

[Andrew Morrow]

Hi Valentin -

This looks like the binary /build/vk/MongoDB3/external/gcc/4.9.1-cms/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.9.1/cc1plus was not able to locate the DT_NEEDED library libcloog-isl.so.4 at runtime when invoked from SCons.

What happens if you invoke /build/vk/MongoDB3/external/gcc/4.9.1-cms/bin/../libexec/gcc/x86_64-redhat-linux-gnu/4.9.1/cc1plus from the bare command line? Does it work? If not, that is the problem to solve.

If that does work, then the question is why it doesn't work when run from SCons. Are you by any chance setting an LD_LIBRARY_PATH or equivalent? Does cc1plus run correctly if you do not have that variable set? I ask because SCons by default does not propagate the environment variables from the calling shell to the environment of its subordinate processes.

Thanks,
Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/1a37e9a9-85d2-4794-9a5e-5be3665104df%40googlegroups.com.

[Valentin Kuznetsov]

Andrew,

yes, everything works from unix shell. Yes, I did setup LD_LIBRARY_PATH. And, I did compile the test when I run within the shell, i.e. I run from my shell

/build/vk/MongoDB3/external/gcc/4.9.1-cms/bin/g++ -o build/scons/sconf_temp/conftest_0.o -c -Wnon-virtual-dtor -Woverloaded-virtual -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -pipe -Werror -O3 -DBOOST_ALL_NO_LIB -D_SCONS -DMONGO_EXPOSE_MACROS -DSUPPORT_UTF8 -DMONGO_OPTIMIZED_BUILD -DMONGO_BYTE_ORDER=1234 -D_FILE_OFFSET_BITS=64 build/scons/sconf_temp/conftest_0.cpp

and it works. So, the problem is really with scons and I need to know how to pass LD_LIBRARY_PATH to it and let it pick up libraries.

Thanks,

Valentin.

[Valentin Kuznetsov]

The solution I found is to write wrappers, e.g. g++wrapper

#!/bin/bash

# setup all environment I need, e.g. it sets GCC_ROOT and LD_LIBRARY_PATH

source /build/vk/MongoDB3/external/gcc/4.9.1/etc/profile.d/init.sh

$GCC_ROOT/bin/g++ $@

and similar for gcc-wrapper, then I run scons as following:

scons --64 --cxx=./g++-wrapper --cc=./gcc-wrapper --config=force

and this time it works. Unless there is a better way I'll stick with that.

[Andrew Morrow]

Hi Valentin -

That would certainly work, however, I have a few comments:

- SCons doesn't propagate the shell environment by default, but you can override that behavior in the MongoDB build by passing the --propogate-shell-environment to scons. Note however, that SCons choice to not make those variables available is there explicitly to permit repeatable builds. Opening the door to arbitrary shell environments affecting the build is risky.

- Your wrapper scripts are certainly a viable approach, but you will need to keep them around, which is sort of a pain.

- How you build your toolchain is, of course, up to you, but I personally would consider a toolchain that required that LD_LIBRARY_PATH be set in order to invoke its components to be broken. You should investigate how to build GCC such that the necessary runtime link path is set in DT_RPATH or DT_RUNPATH for the compiler components, so that you don't need LD_LIBRARY_PATH at all.

- If the custom toolchain that you have built includes a dynamic libstdc++, you must ensure that this libstdc++ is found by mongod when it is run, rather than a system default one. To do so when libstdc++ is in a non-standard location may require that you set a runpath for the mongo binaries that points into your custom toolchain's library directory, if GCC is not automatically doing this for you. Otherwise you will also need LD_LIBRARY_PATH in your environment when you run mongod. Potentially, you can work around this by tunneling in an RPATH setting by customizing the LINKFLAGS Variable to scons, by saying 'scons LINKFLAGS=-Wl,-rpath=/path/to/needed/runtime/lib'

- In my opinion, you should try to avoid LD_LIBRARY_PATH if at all possible.

I hope the above proves useful. Please let me know if there is anything more I can help you with.

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/3b82a084-3366-4b71-b704-cb2915dbbbce%40googlegroups.com.

[Valentin Kuznetsov]

Andrew,

I would agree with all your points, but also complement them with our build environment. For our production node we built everything, gcc/python/anything.

We package them in RPMs and any new package has its own version during the build. RPMs allows relocation and we rely on this for deployment.

Yes, I discovered that I need to pass LD_LIBRARY_PATH via --propogate-shell-environment because scons invokes python to make error_codes files.

Since it picks the one from environment I set in my wrapper it *misses* its dynamic libs which can only passed via LD_LIBRARY_PATH.

To address your points we do:

- keep wrappers in local build area

- keep consistent environment during deployment, all is done via RPM and we use relocation features to switch from local build to production environment

So sum-up, it's a pity that MongoDB builds relies on scons instead of normal configure/Makefile approach. It makes things more complex in my mind and leaves open such corner cases as ours where we built in controlled (i.e. non-system default) way. As you pointed out, there are various pitfalls we may encounter during our builds, but we can't change requirements for our systems and must build everything by ourselves via explicit approach.

But I really appreciate your help as well as help from MongoDB team. So far, we're able to move on with every MongoDB release.

Thanks,

Valentin.

[Andrew Morrow]

On Tue, Mar 10, 2015 at 8:22 PM, Valentin Kuznetsov <vku...@gmail.com> wrote:

Andrew,

I would agree with all your points, but also complement them with our build environment. For our production node we built everything, gcc/python/anything.

We package them in RPMs and any new package has its own version during the build. RPMs allows relocation and we rely on this for deployment.

Yes, I discovered that I need to pass LD_LIBRARY_PATH via --propogate-shell-environment because scons invokes python to make error_codes files.

Since it picks the one from environment I set in my wrapper it *misses* its dynamic libs which can only passed via LD_LIBRARY_PATH.

Yes, I had gathered that you were doing something like this. For that environment LD_LIBRARY_PATH is straightforward and will just work. However, if you control the build of all components, potentially you could use DT_RPATH or DT_RUNPATH with ORIGIN processing to achieve the same thing? Of course there may be reasons that I would not be aware of why that would not work for you. Just a thought. I have a personal dislike for LD_LIBRARY_PATH.

 

To address your points we do:

- keep wrappers in local build area

- keep consistent environment during deployment, all is done via RPM and we use relocation features to switch from local build to production environment

So sum-up, it's a pity that MongoDB builds relies on scons instead of normal configure/Makefile approach. It makes things more complex in my mind and leaves open such corner cases as ours where we built in controlled (i.e. non-

Perhaps, but the larger issue is that autotools doesn't work on native Windows, and we aren't willing to maintain two build systems for the server.

 

system default) way. As you pointed out, there are various pitfalls we may encounter during our builds, but we can't change requirements for our systems and must build everything by ourselves via explicit approach.

But I really appreciate your help as well as help from MongoDB team. So far, we're able to move on with every MongoDB release.

I'm very happy to hear that. Please let me know if there is any further help we can provide on this issue.

Andrew

 

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/4c45e19f-cf72-4a49-b9b9-05962e5e8970%40googlegroups.com.