lldb 3.4 rc1 is failing with gcc 4.6

We noticed this too, but assumed it was just progress on the uptake of cpp11 features. We would rather not need to upgrade to 4.8 either, but understand if this is just the path that is being taken.

Colin

FWIW I have the build process we’re using over here on Ubuntu 12.04 building with gcc 4.8.2 since I hit build errors on that path as well. I tried several other paths that each failed for different reasons before settling on that one.

AFAIK, gcc 4.8 is not part of the repositories of Ubuntu 12.04... So, it
would need to add extra packages to build lldb ... :confused:

Out of curiosity, are Clang and libc++ not options on these platforms? I don’t have much recent experience outside Mac OS X but building with Clang and libc++ would ensure that you guys have as similar an environment to the one we use as possible…

Sean

clang could be an option but we prefer to bootstrap with the recommended compiler (which is still gcc under Debian). About libc++, it has not been tested enough under Debian for now. Well, I think that diversity is good and having the same base code compiled with different compiler and versions improve the quality of the software (even if here, it is a drawback :slight_smile: Sylvestre

I pulled llvm/clang/lldb from sources today and tried compiling lldb using clang on Ubuntu 12.04. It failed with include file issues:


In file included from /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/atomic:38:
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/bits/c++0x_warning.h:32:2: error:
      This file requires compiler and library support for the upcoming ISO C++
      standard, C++0x. This support is currently experimental, and must be
      enabled with the -std=c++0x or -std=gnu++0x compiler options.
#error This file requires compiler and library support for the upcoming \

/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/atomic:68:5: error:
      unknown type name 'constexpr'
    constexpr atomic_bool(bool __i) : _M_base(__i) { }

atomic is in /usr/include/c++/4.6, and is included from llvm/tools/lldb/include/lldb/Utility/SharingPtr.h .

Ted

FWIW - here’s the build script I used to build LLDB on Ubuntu 12.04:

First make sure you have the following packages installed:
sudo apt-get install build-essential gcc-multilib git libedit-dev libmpc-dev libmpfr-dev python-dev swig

Uncompress the attached script to some directory in your path. It’s a python script with a few other python modules pulled in.

Then run it with build-lldb.py -h to see the options.

Typically I run it like so:
cd {some_root_directory}
PYTHONUNBUFFERED=true build-lldb.py -s --base-compiler=gcc -c tot -j 16 -d 2>&1 | tee tot-build.log

This will do a ton of things. It will create a directory called tot, download llvm, clang, lldb, check if your gcc is less than 4.8, and if so, downloads gcc 4.8.2 and installs it in the tot tree (no sudo access needed). It then goes ahead and builds LLVM with gcc. It will then install the built LLVM bits (including lldb) into tot/final.

It has other options, like using a --stage1 to build a clang compiler from the current llvm tree using whatever the base compiler is, but since I haven’t had much luck with getting that working, I am not promising it works since I hit an internal build error in clang building all of LLVM with the stage 1 clang. I’ll eventually get back to that since I’d like to be able to build everything with the latest clang, particularly if we’re doing work on debug info support.

To run the LLDB you built, you’ll need to include the gcc 4.8.2 path (tot/gcc/lib64) in your LD_LIBRARY_PATH so it picks up the newer libstdc++ built with gcc 4.8.2.

cd {some_root_directory - from above}
LD_LIBRARY_PATH=pwd/tot/gcc/lib64 tot/final/bin/lldb

If this ends up being a useful script for more, we can put it somewhere shared. For now I’m just using it internally here. I’m sure I’ll continue to tweak it as we figure out our workflow over here (changing compilers, learn more about other ways of building that might make more sense, etc.).

Let me know if that gets you further.

build-lldb-20131125-1409.tar.gz (3.7 KB)

I should point out a few more things about that script:

By this:

… and if so, downloads gcc 4.8.2 and installs it in the tot tree …

I mean it will download the source and build the c and c++ compilers from source, not a prebuilt bundle.

I build on an x86_64 Ubuntu 12.04 system, a 32-bit system is untested.

If the directory specified by -c already exists, it leaves it there. If no -c is specified, it uses the current directory as the root. {root}/llvm is used for the llvm source tree (and for llvm/tools/clang and llvm/tools/lldb). If those directories already exist, the -s option will do a git pull rather than a git clone. The gcc code is unpacked to {root}/gcc-4.8.2, built in {root}/gcc-build, and installed into {root}/gcc. llvm is built in {root}/final-build, and installed into {root}/final. If the stage1 clang is used, it’s built into {root}/stage1-build and installed into {root}/stage1.

It’s probably not appropriate as is for a serious dev workflow since the -s option is probably not what is wanted for managing work branches and the like; however, it is probably ok as a starting point for some kind of automated build script.

Hope that’s helpful.

Well, I am doing the packaging. So, I have to rely on the packages
provided by the system...
Rebuilding gcc itself is no solution I am considering :wink:

Sylvestre

I went and built gcc 4.8.2 on Ubuntu 12.04. I had to jump through several
hoops - missing packages, and
I had to set C_INCLUDE_PATH for it to find things like bits.h.

Once that was done I build llvm/clang/compiler-rt/lldb. I had to unset
C_INCLUDE_PATH so it could find features.h.

Finally I ran lldb. It failed with this message:
Debug+Asserts/bin/lldb: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
`GLIBCXX_3.4.18' not found

I was able to get lldb to run by setting LD_LIBRARY_PATH to point to the gcc
4.8.2 install/lib64 directory.
Any thoughts on how I can build with the system's GLIBCXX? I'd rather not
have to ship a gcc library with
my product.

Ted