[lldb-dev] lldb 3.4 rc1 is failing with gcc 4.6

[Todd Fiala]

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.


On Mon, Nov 25, 2013 at 2:14 PM, Todd Fiala <tfiala at google.com> wrote:

> 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.
>
>
> On Mon, Nov 25, 2013 at 1:48 PM, Ted Woodward <ted.woodward at codeaurora.org
> > wrote:
>
>> 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
>>
>>
>>
>> From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu]
>> On Behalf Of Sylvestre Ledru
>> Sent: Monday, November 25, 2013 7:57 AM
>> To: lldb-dev at cs.uiuc.edu
>> Subject: Re: [lldb-dev] lldb 3.4 rc1 is failing with gcc 4.6
>>
>> On 25/11/2013 14:46, Sean Callanan wrote:
>> Out of curiosity, are Clang and libc++ not options on these platforms?
>> 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.
>>
>>
>>  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...
>> 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 :)
>>
>> Sylvestre
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131125/c511f511/attachment.html>