Manual Installation for Linux LLDB
These instructions have only been vetted on Ubuntu 19.10, but some of the concepts should be generally applicable. These instructions are really only intended for developers who cannot stand how slow gdb
is on large libraries/executables, and prefer the speed of lldb
. (Clang may also be faster at compiling templates, of which there are a fair amount in libMesh/MOOSE).
Compilers
Install a clang compiler. You can choose to do this manually, but it's probably easier to just use your package manager. On Ubuntu based Linux systems:
Ubuntu generally has several options for clang compilers, for instance on 19.10 there are clang-6, clang-7, clang-8, clang-9 and a default clang package. I elect to go with the newest available package. After installation:
Now in order to use various (optional) PETSc packages, we must also have an available fortran compiler. The de facto choice is gfortran
:
Compiler flags
Now there are some subtleties here. At least on my system by default the clang compilers do not generate position-independent code or position-independent executables, e.g. by default clang is compiling as if with the -fno-PIC -fno-PIE
flags. With these default settings, configuration of fortran support for MPICH will fail because of an inability to link objects generated by gfortran
and objects generated by clang
. To fix this we need to explicitly pass the -fPIC -fPIE
flags:
At the time of writing, clang
is known to have issues reading debug info from libstdc++
. The most straightforward fix to this is to have clang
institute its own debug information:
Note that we do not pass this option into CPPFLAGS
because gfortran
doesn't recognize the -fstandalone-debug
option.
Build MPICH
With our compilers and compiler flags set, we can proceed to building our MPI compilers. The git
command below assumes you have ssh
keys setup on github. If you do not, then you can clone using the https
protocol. Moreover, if you are building from the git
sources, you will need autotools installed in order to run autogen.sh
. You can install autotools using your package manager, or you can actually build autotools in libMesh, by cd'ing into the root of the libMesh source directory and executing ./bootstrap --build-autotools
. You can also download an mpich tarball if you prefer to avoid the git and autotools stages.
With the MPICH compilers built, we can export them to our PATH
:
Build PETSc
PETSc prefers to do most configuration detection on its own so we:
We are going to build PETSc using our MOOSE submodule script, so make sure you've cloned MOOSE. (See Cloning MOOSE)
Build libMesh
Before building libMesh, let's set compilers again. If you have ccache
available in your environment:
else:
Now let's build!
Build WASP
Building WASP is also necessary. With the compilers already set in the above step, we only need to run the following commands:
Build MOOSE
I always prefer to make sure that all potentially stale object files have been removed from my MOOSE directory before trying to link with new libraries. If using git clean
, make sure that you've checked-in any untracked files you want preserved. I'm also going to be passing TAGS
as an exclusion pattern because I use etags a lot when developing.
Installing and Using LLDB
This next set of instructions is very much Ubuntu 19.10 specific, but it may still be beneficial across platforms and across distribution versions. I built my stack using clang-9
, so I'm going to use the corresponding lldb
version:
If you try to use lldb-9
straight out of the box, you're probably going to see some troubling messages when you begin trying to debug:
The python import errors are irritating, but more irritating perhaps is that if you attempt to print container information (like for a std::vector
), you're going to get something ugly:
So there are several problems here stemming from lldb
interactions with python. Let's debug. We can first check where lldb
things its python information is going to come from:
Hmm, so the lldb-9
binary is expecting to execute python3 code, yet the apt
package manager has installed a python2 support package. Let's install the correct python3 version:
Wow, even after we installed the python3 lldb
support package, we still have lldb
looking for its python module in a directory that doesn't exist. Luckily, we have Stack Overflow. The python3-lldb-9
package actually installs its python bindings in /usr/lib/llvm-9/lib/python3.7/site-packages
. So we need to create symlink from where the lldb-9
binary is looking for the module to where the module is actually located:
Now what happens in our debugger?:
Ah, beautiful code! As a final step, if for some reason you ever wanted to load the lldb
module inside of a standard python3 interpreter, you need to perform one additional symlink because:
The difference here is that the __init__.py
script in the lldb
python module does an absolute import when run from inside the lldb
binary, but attempts a relative import when run from inside the python interpreter. The problem is that:
So let's create the final additional symlink:
lldb
import inside a standard python interpreter should now be successful: