Compile failure on FreeBSD

I'm trying to build lldb on FreeBSD (stable/9) using the system's
clang 3.2 and libc++, and have run into a couple of small nits along
the way. This is at llvm svn r183025.

1) Missing header for free() def'n (perhaps it leaks in from string.h
on other platforms). On a quick glance I'm not sure string.h is even

Index: source/Core/Mangled.cpp

Hi Ed! Thanks for the patches; I committed the first two hunks (r183032)!

However, the third looks a bit suspicious:

Hi Ed! Thanks for the patches; I committed the first two hunks (r183032)!


However, the third looks a bit suspicious:

+ Plugins/Process/Linux

Should that read Plugins/Process/FreeBSD instead?

Yep, a cut-and-pasteo. Updated hunk, compile tested only (still fails to link):

+ Plugins/Process/FreeBSD
+ Plugins/Process/POSIX
+ )
+endif ()

(It compiled with my original error, but the first line should be
included for consistency with the Linux config, I think.)

Everything compiles, but fails to link -- a handful of undefined
references from Commands to BreakpointIDList. A specific example:
undefined reference to

It'll take a bit of digging since this is my first real foray into CMake.


Just a nit: the other headers are old-style .h files, but then you
include C++-style <cstdlib>. Maybe it is more consistent to use
<stdlib.h> here? I am not sure what the overall lldb convention is,

Btw, really nice that you can spend some time on lldb for FreeBSD. :slight_smile:


Thanks Ed; committed the fix in 183038.

Regarding the linking error, what library (or utility) is failing to link?
As far as I can tell (by inspecting source/CMakeLists.txt) lldbBreakpoint
(contains BreakpointIDList class) is required for linking Is
it the lldbCommands library that's failing? If so, the fix might be as
simple as making lldbCommands depend on lldbBreakpoint.


Thanks Dimitry; replaced with a C-style include, in 183039!


Yes, it's exactly this. I'm not sure how the dependency is expressed
for CMake, but I found that swapping the order of lldbCommands and
lldbBreakpoint in lldb/source/CMakeLists.txt worked around the issue,
and links.

Hmm, so while that approach might work in this case, it won't be fun to
maintain this correct ordering in the long run. If you have a moment,
could you try the below fix instead? I think it's a more generic solution
to the problem at hand. If it works, I will commit post haste.

Index: CMakeLists.txt

Right, I just wanted to verify that it was (only) a link ordering
problem. I can confirm that it works with your patch.

Thanks for the confirmation; committed in 183109.