When your build environment sucks…

I recently ran into a mysterious C++ error that was deeply rooted in the C++ standard library.  All that was happening was that I was trying to initialize an std::atomic variable with a value.  But this was the result:

/usr/include/c++/v1/atomic:945:58: error: no viable conversion from
          'C4ReplicatorStatus' to '_Atomic(C4ReplicatorStatus)'
      _LIBCPP_CONSTEXPR __atomic_base(_Tp __d) _NOEXCEPT : __a_(__d) {}
                                                           ^    ~~~
/usr/include/c++/v1/atomic:1054:51: note: in instantiation of member function
          'std::__1::__atomic_base<C4ReplicatorStatus, false>::__atomic_base'
          requested here
      _LIBCPP_CONSTEXPR atomic(_Tp __d) _NOEXCEPT : __base(__d) {}
                                                    ^
/home/jenkins/workspace/litecore-linux/label/s61112cnt72 (litecore)/Replicator/c4Replicator.cc:99:6: note:
          in instantiation of member function
          'std::__1::atomic::atomic' requested here
        ,_status(_replicator->status())
         ^

The build machine being used is a VM running CentOS 7.2.  For whatever reason, CentOS has a real aversion to upgrading anything or making anything new easily available.  Maybe it’s so that Red Hat can sell Enterprise Linux?  Anyway, the latest version of clang that comes prebuilt for it is

clang –version
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: x86_64-redhat-linux-gnu
Thread model: posix

This version was released on 19 Jun 2014.  I had a sneaking suspicion that it was too old and had a bug.  So what should I do in this situation?  I can’t find anything newer that is available for CentOS 7.2 so I am forced to build it myself.  After realizing that building the default settings for LLVM will take up more space than is available on the VM hard disk (it was 18 GB when I ran out of space) I decided to experiment and find out how to build exactly only what I need.  Here is the list of steps I came up with.  I wanted to build version 3.8, which is a known working version on another build machine I have (Ubuntu).

svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_380/final llvm
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_380/final clang

That’s all I need, the other extras like compiler-rt and such would just take up space.  So now onto the actual build.

cmake -G “Unix Makefiles” -DLLVM_TARGETS_TO_BUILD=”X86″ -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_TOOLS=OFF -DCMAKE_INSTALL_PREFIX=/usr/local ../llvm

This instructs cmake to build a Makefile that will create a release build without any of the extra tools (also unneeded) and only for creating x86 (and I assume x86_64 also) since I don’t need any cross compiling capabilities.  This will spin for a while and then I simply run

make -j4

And wait…the build on the VM took about 10-15 minutes.  After that just to be sure I ran make clang-check to run the test suite.  It passed fine, as I hoped.  After a quick make install clang got installed into /usr/local where it supersedes the built in old version by coming first in the path.

clang –version
clang version 3.8.0 (tags/RELEASE_380/final 299629)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin

Recompiling with this compiler fixed the scary error above and I was unblocked to continue work on other more important things.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s