LLDB build... works!

[petah]

Hi Eran,

I rebuilt CL trunk with LLDB, the main challenge was installing llvm 3.5 on Debian Wheezy because it has no backport for it, you'd have to use testing or unstable... I couldn't build llvm with gcc-4.7... and there's no backport for gcc 4.8 either. On one machine I used my previous clang 3.3 to build clang 3.5, then uninstalled the old version before installing the new one, on the other I'm currently building gcc-4.9.

It took me all night so I'm too tired to sound excited by I am!

LLDB works great but it doesn't set the working directory to the one specified in the UI prefs, nor in argv[0], so some builds don't work. There was also something weird about the compiler detection but it happened only once so may be a fluke.

anyway congrats & cheers!

-- p

[eranif]

You don't need to install lldb-3.5 ... codelite comes with an already compiled liblldb.so for Ubuntu/Debian (check under codelite-src/sdk/lldb/lib/unix/lib/<arch>)
and the CMake should have picked it up (in fact, the lldb.so under codelite-src/sdk/lldb/lib/unix/lib/<arch> was built on Debian Wheezy )

Eran

[petah]

You don't need to install lldb-3.5 ... codelite comes with an already compiled liblldb.so for Ubuntu/Debian (check under codelite-src/sdk/lldb/lib/unix/lib/<arch>) and the CMake should have picked it up

Hmm, you're right but when rebuilding CL on one pc I got an error about not having "lldb-dev" installed so I went on trying to install it myself. On the other pc it picked up your pre-built lldb... dunno why.

(in fact, the lldb.so under codelite-src/sdk/lldb/lib/unix/lib/<arch> was built on Debian Wheezy )

Wow so you built every from source with only Wheezy's gcc 4.7? do you mind sharing your recipe? AFAIK there's no clang 3.5 release, only 3.4 and trunk... on which I'm not even sure I get the same code version between svn llvm and svn clang!

The worst part is building libc++ and libc++abi, if you used the latter at all. I tried a bunch of online instructions but there are so many variations (with ABI libsupc++, libstdc++, etc.) and on install I get weird stuff like headers in /usr/include/c++/v1/c++/v1/chrono (with double sub-dirs) and /usr/include/c++/v1//algorithm. cmake doesn't create a 'make uninstall' target so it's a pain in the ass to rebuild.

Then I have to rebuild wx with g++ -std=c++11 so wx uses std::unordered_map and not the tr1 version, then CL can compile my projects but won't link them. The debug build is static and non-monolithic.

Everything is waaaay easier in Debian testing w/ gcc 4.8 and libc++-dev but I was hoping to keep one pc on wheezy.

btw I get CL crashes without logging if I open build settings and there's no loaded workspace; the gdb trace indicates that AdvancedDlg::LoadCompilers() calls Workspace::GetProjectBuildConf(). I was going to look into this deeper before getting sucked in by the libc++ black hole

thx a lot & cheers!

-- p

[eranif]

Wow so you built every from source with only Wheezy's gcc 4.7?

I can't take the credit here... David built it on Debian, I built it for Windows (!!) and OSX

btw I get CL crashes without logging if I open build settings and there's no loaded workspace;

So don't do this ? , thanks I will look into it

Eran

[eranif]

o don't do this ? , thanks I will look into it

Fixed

Eran

[petah]

thx I ping'ed David. Hopefully it doesn't require installing gcc4.8 from debian testing.

It'd be great if on the wiki every pre-built binary in CL had a matching build instruction page, so people like me don't end up haplessly poking around like a blind elephant in a china store

cheers!

-- p

[DavidGH]

Hi,

I built using the standard wheezy toolchain, following the instructions from http://codelite.org/Developers/HomePage#toc3; the 'configure' method as I couldn't get the cmake one to work (though I didn't try very hard), and I didn't use a 'build' subdir for the same reason.

I used a revision from a few weeks ago, r207621, but there's no reason to suppose that it would be much different with today's. It needed the following to make it compile:

Code: Select all

Index: include/lldb/DataFormatters/TypeFormat.h
===================================================================
--- include/lldb/DataFormatters/TypeFormat.h    (revision 207622)
+++ include/lldb/DataFormatters/TypeFormat.h    (working copy)
@@ -229,7 +229,7 @@
         typedef std::shared_ptr<TypeFormatImpl_Format> SharedPointer;
         typedef bool(*ValueCallback)(void*, ConstString, const TypeFormatImpl_Format::SharedPointer&);
         
-        virtual ~TypeFormatImpl_Format () = default;
+        virtual ~TypeFormatImpl_Format () noexcept (true) {}
         
         lldb::Format
         GetFormat () const
@@ -272,7 +272,7 @@
         typedef std::shared_ptr<TypeFormatImpl_EnumType> SharedPointer;
         typedef bool(*ValueCallback)(void*, ConstString, const TypeFormatImpl_EnumType::SharedPointer&);
         
-        ~TypeFormatImpl_EnumType () = default;
+        ~TypeFormatImpl_EnumType () noexcept (true) {}
         
         ConstString
         GetTypeName ()
Index: source/DataFormatters/TypeFormat.cpp
===================================================================
--- source/DataFormatters/TypeFormat.cpp        (revision 207622)                                                                                                                                                                     
+++ source/DataFormatters/TypeFormat.cpp        (working copy)                                                                                                                                                                        
@@ -201,7 +201,8 @@                                                                                                                                                                                                                   
             if ( (type_sp->GetClangForwardType().GetTypeInfo() & ClangASTType::eTypeIsEnumeration) == ClangASTType::eTypeIsEnumeration)                                                                                              
             {                                                                                                                                                                                                                        
                 valobj_enum_type = type_sp->GetClangFullType();                                                                                                                                                                      
-                m_types.emplace(valobj_key,valobj_enum_type);                                                                                                                                                                        
+                //m_types.emplace(valobj_key,valobj_enum_type);                                                                                                                                                                      
+                m_types.insert( std::pair<void*,ClangASTType>(valobj_key,valobj_enum_type) );                                                                                                                                        
                 break;                                                                                                                                                                                                               
             }                                                                                                                                                                                                                        
         }                    

I don't think I missed anything, but let me know if you have problems.

Regards,

David

[petah]

damn, I had started patching Clang's code, I fixed the noexcept error but stalled on the std::emplace() and since the same code worked with gcc 4.8 I reverted everything. I guess I'll revert my revert:)

Do you get new c++11 headers after the whole procedure? are they in /usr/include/c++/v1/ ? Or do you get them from elsewhere and don't even bother with libc++?

I had other issues reconfiguring wx, f.ex. so its wxHashMap uses the native std::unordered_map, we'll see.

thx!

-- p

[DavidGH]

Do you get new c++11 headers after the whole procedure? are they in /usr/include/c++/v1/ ? Or do you get them from elsewhere and don't even bother with libc++?

I'm not sure I understand the question, but I wasn't interested in building anything except lldb, and I didn't make-install anything to anywhere; I just grabbed liblldb.so and copied it into codelite-src/sdk/lldb/...

[petah]

I meant that building clank trunk without a new runtime lib (libc++ or libstd++) doesn't improve C++11 because Wheezy's still using gcc 4.7's outdated headers. F.ex. std::emplace() is missing in gcc4.7 headers, which is why you had to patch lldb's source code, but exists in libc++ and gcc4.8 and up.

Anyway I managed to build gcc4.9 with 4.7, then should be able to use gcc4.9's new headers and runtime when compiling lldb and my c++11 projects with clang++.

PS for Eran: I tried to configure a new CL compiler for gcc4.9 without having to 'sudo make install' it (just a user-space --prefix) but had trouble with the advanced -> global compiler paths that can't override system paths but only append to them (AFAIK), getting -rpath to apply to libstdc++ and escaping $ in pre/post-build commands. I probably missed something, otherwise it'd be helpful to test new compilers without root modifications.

thx & cheers,

-- p