Compile error: mongodb source code on Ubuntu 14.04, gcc 4.8.2 <Compiler must support a thread local storage class for trivially constructible types>

[Atish Kathpal]

Folks,

I cloned the latest MongoDB source code from github and followed the instructions on https://docs.mongodb.org/manual/contributors/tutorial/build-mongodb-from-source/ 

However I see the following error on running scons all:

<quote> 

....

Checking for storage class thread_local (cached) no

Checking for storage class __thread no

Checking for storage class __declspec(thread) (cached) no

Compiler must support a thread local storage class for trivially constructible types.

</quote>

I am not clear why I am hitting this problem. 

GCC version: 4.8.2

OS: Ubuntu 14.04

SCONS: 2.3.0

Note: The code however compiles very well on my macbook (where I had been trying out changes to the sources as well), with gcc that comes with Xcode.

If I write a test code that uses __thread storage class, it works just fine on the machine.

Regards

Atish

[Andrew Morrow]

This usually indicates that linking is failing for some reason during the configure step. Could you please provide:

- The git SHA of the repo that you are trying to build

- The complete SCons invocation you isssued

- The contents of the file build/scons/config.log after re-running SCons with the --config=force flag?

Thanks,

Andrew

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev...@googlegroups.com.
To post to this group, send email to mongo...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-dev.
For more options, visit https://groups.google.com/d/optout.

[Atish Kathpal]

Thanks for the response Andrew. I think I have found the issue here.

On going over the scons output, I noticed that it was printing some more unexpected stuff, like it was detecting the C++ compiler to be Clang, while Clang was not even installed on the Ubuntu VM. So I guess the issue was that I directly copied the sources from my macbook to the Ubuntu VM and with that some meta-files (due to previous builds done on Mac) got copied that were making SCons believe the machine has Clang?

On copying pristine sources (.zip) from github master branch, directly to my Ubuntu VM, things are compiling correctly. 

Thanks

Atish

PS: Thing is that I could not clone the sources to Ubuntu VM directly from github as internet access is restricted for the VM.

[MarkCallaghan]

I got this while building 3.3.5 with a gcc 4.9 compiler. My builds are harder because I have to set paths for compilers, include and library paths. Adding "-lrt" to LINKFLAGS fixed it for me.

echo scons --config=force \

  CPPPATH=$EXTRAINC \

  LINKFLAGS="$MY_LINKFLAGS" \

  RPATH=$MY_RPATH \

  CXX=$CXX \

  CC=$CC \

  LIBPATH=$MY_LIBPATH \

  --prefix=$PREFIX -j$PAR --allocator=$ALLOC --disable-minimum-compiler-version-enforcement --nostrip --opt=on  $ACTION

This was at the end of config.log when the error occurred:

file /s/bld/mongodb-src-r3.3.5/SConstruct,line 2206:

        Configure(confdir = build/scons/sconf_temp)

scons: Configure: Checking for storage class thread_local 

build/scons/sconf_temp/conftest_33.cpp <-

  |

  |thread_local int tsp_int = 1;

  |int main(int argc, char** argv) {

  |    return !(tsp_int == argc);

  |}

  |

Compiling build/scons/sconf_temp/conftest_33.o

Linking build/scons/sconf_temp/conftest_33

/mnt/gvfs/third-party2/jemalloc/d9acac8a9a2c9378eb696e22ffa8bd0e97d9206b/master/gcc-4.9-glibc-2.20/a6c5e1e/lib/libjemalloc.a(nstime.o): In function `jemalloc_je_nstime_update':

/home/engshare/third-party2/jemalloc/master/src/jemalloc.git-trunk/src/nstime.c:125: undefined reference to `clock_gettime'

/home/engshare/third-party2/jemalloc/master/src/jemalloc.git-trunk/src/nstime.c:127: undefined reference to `clock_gettime'

collect2: error: ld returned 1 exit status

scons: Configure: no

scons: Configure: Checking for storage class __thread 

build/scons/sconf_temp/conftest_34.cpp <-

  |

  |__thread int tsp_int = 1;

  |int main(int argc, char** argv) {

  |    return !(tsp_int == argc);

  |}

  |

Compiling build/scons/sconf_temp/conftest_34.o

Linking build/scons/sconf_temp/conftest_34

/mnt/gvfs/third-party2/jemalloc/d9acac8a9a2c9378eb696e22ffa8bd0e97d9206b/master/gcc-4.9-glibc-2.20/a6c5e1e/lib/libjemalloc.a(nstime.o): In function `jemalloc_je_nstime_update':

/home/engshare/third-party2/jemalloc/master/src/jemalloc.git-trunk/src/nstime.c:125: undefined reference to `clock_gettime'

/home/engshare/third-party2/jemalloc/master/src/jemalloc.git-trunk/src/nstime.c:127: undefined reference to `clock_gettime'

collect2: error: ld returned 1 exit status

scons: Configure: no

scons: Configure: Checking for storage class __declspec(thread) 

build/scons/sconf_temp/conftest_35.cpp <-

  |

  |__declspec(thread) int tsp_int = 1;

  |int main(int argc, char** argv) {

  |    return !(tsp_int == argc);

  |}

  |

Compiling build/scons/sconf_temp/conftest_35.o

build/scons/sconf_temp/conftest_35.cpp:2:11: error: expected constructor, destructor, or type conversion before '(' token

 __declspec(thread) int tsp_int = 1;

           ^

build/scons/sconf_temp/conftest_35.cpp: In function 'int main(int, char**)':

build/scons/sconf_temp/conftest_35.cpp:4:14: error: 'tsp_int' was not declared in this scope

     return !(tsp_int == argc);

              ^

scons: Configure: no

[Andrew Morrow]

Hi Mark -

Just wanted to double check that when you say "fixed it for me" that you are now getting a working 3.3.5 build with your LINKFLAGS addition? Also, I wanted to alert you that the next development version of MongoDB, 3.3.6, is going to require GCC 5.3. We will be sending an email to mongodb-dev with more details on the update.

Thanks,

Andrew

[MARK CALLAGHAN]

My at-home test servers use Ubuntu 14.04 LTS. Just checked apt-cache and the choices are gcc 4.7, 4.8 or 4.9. How do I get gcc 5.3 on Ubuntu 14.04? Do you want me to build from source? I'd rather not.

It took me most of the day but I have a working scons build using my production toolchain. Lost too much time figuring out the separator for scons environment variables like CPPPATH and LIBPATH. The separator is a space (" ") rather than something I expected like ":". Searches via google did not find anything useful. If the world used fewer build tools, then I would have fewer build tools to dislike.

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev...@googlegroups.com.
To post to this group, send email to mongo...@googlegroups.com.

Visit this group at https://groups.google.com/group/mongodb-dev.

For more options, visit https://groups.google.com/d/optout.

--

Mark Callaghan
mdca...@gmail.com

[Jonathan Reams]

Hi Mark, if your system doesn't have GCC 5.3, you can use Clang 3.4 or above instead.

Jonathan

[MarkCallaghan]

On Wednesday, April 27, 2016 at 1:59:14 PM UTC-7, Jonathan Reams wrote:

Hi Mark, if your system doesn't have GCC 5.3, you can use Clang 3.4 or above instead.

That will work for me. Ubuntu 14.04 offers it.

[MarkCallaghan]

I have a working build. I was confused by the path separator for CPPPATH and LIBPATH. I had to use a space rather than a colon. I appreciate the responses.
http://smalldatum.blogspot.com/2016/04/fun-with-scons-while-building-mongodb.html

[Jonathan Reams]

The space-separated variables syntax is actually a customization on our end. There are actually a bunch of variables we define, and you can see all of them, their defaults, and their syntax by running scons --variables-help.

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev...@googlegroups.com.
To post to this group, send email to mongo...@googlegroups.com.

Visit this group at https://groups.google.com/group/mongodb-dev.

[MARK CALLAGHAN]

Nothing in that output suggests that the separator is a space.

CPPPATH: Adds paths to the preprocessor search path
    default: None
    actual: None

LIBPATH: Adds paths to the linker search path
    default: None
    actual: None

LIBS: Adds extra libraries to link against
    default: None
    actual: None

LINKFLAGS: Sets flags for the linker
    default: None
    actual:

--

Mark Callaghan
mdca...@gmail.com

[Jonathan Reams]

Then that is a bug that I will fix!

[Andrew Morrow]

The default variable parsing mode actually varies by platform. On POSIX systems, we split Variable values with python.shlex in POSIX mode, while on Windows, we split with python.shlex in 'other' mode. You can override this default splitting mode with the --variable-parse-mode flag.

The short version though is that arguments are split according to python.shlex, in whatever mode you chose:

https://docs.python.org/2.6/library/shlex.html#parsing-rules

I agree with you and Jonathan that this should be better documented.