Compiling LLDB on Linux, certain types don't exist at all?

Hello,

I currently have spent a little bit of time in the past day or two
trying to get the latest copy of LLDB compiling on Linux.

Most of the work has been pretty easy - stuff GCC is a little anal
about for the most part (like commas at the end of enumeration
declarations) or simple fixes (missing #includes).

Currently I can get a bit of stuff under source/ to build with these
simple changes such as API and Breakpoint, but when compiling Commands
I get the following error, and I have no idea where this comes from.

Background: I have checked out LLVM and clang, revision 121655 which
is the latest that LLDB works with. I checked them out into a normal
directory structure and then built llvm + clang in debug mode. I then
took a copy of the LLDB checkout, and put it under llvm/tools, so that
it could find all the needed LLVM headers and whatnot.

On Mac OS X, from what I can tell the build-llvm.pl scripts is called
to invoke an LLVM build, and the resulting shared libraries and clang
library are stuffed into the llvm.zip in the top level directory as
well as all the needed includes, which is checked into SVN, so for
most people they can just be unzipped and linked against when
building, without checking out clang/llvm manually, because lldb lags
behind llvm/clang trunk a little bit. I have not tried getting this
script working on linux, because I don't know the full usage of
build-llvm.pl or it's ramifications on the Mac OS X build (I have an
OS X machine at home, but I haven't built LLDB using it.) I've tried
to keep changes minimal. So I opted to just put lldb under an llvm
checkout at the specified revision, since it looked like the Makefile
was intended to be used that way.

After having a built llvm+clang, and then attempting to build lldb, I
get into source/Breakpoints when this occurs:

llvm[2]: Compiling CommandObjectCall.cpp for Debug+Asserts build
In file included from CommandObjectCall.h:17,
                 from CommandObjectCall.cpp:10:
/home/a/src/llvm-lldb_build/tools/lldb/source/Commands/../../include/lldb/Interpreter/CommandObject.h:117:
warning: type qualifiers ignored on function return type
CommandObjectCall.cpp: In constructor
‘lldb_private::CommandObjectCall::CommandObjectCall()’:
CommandObjectCall.cpp:115: error: no matching function for call to
‘lldb_private::CommandObject::CommandObject(const char [5], const char
[17], NULL, int)’
/home/a/src/llvm-lldb_build/tools/lldb/source/Commands/../../include/lldb/Interpreter/CommandObject.h:57:
note: candidates are:
lldb_private::CommandObject::CommandObject(lldb_private::CommandInterpreter&,
const char*, const char*, const char*, uint32_t)
/home/a/src/llvm-lldb_build/tools/lldb/source/Commands/../../include/lldb/Interpreter/CommandObject.h:27:
note: lldb_private::CommandObject::CommandObject(const
lldb_private::CommandObject&)
CommandObjectCall.cpp:126: error: ‘eArgTypeType’ was not declared in this scope
CommandObjectCall.cpp:132: error: ‘eArgTypePlain’ was not declared in this scope
CommandObjectCall.cpp:136: error: ‘eArgTypeArgType’ was not declared
in this scope
CommandObjectCall.cpp: In member function ‘virtual bool
lldb_private::CommandObjectCall::Execute(lldb_private::Args&,
lldb_private::CommandReturnObject&)’:
CommandObjectCall.cpp:171: error: ‘interpreter’ was not declared in this scope
CommandObjectCall.cpp:295: error: ‘ExecutionResults’ is not a member
of ‘lldb_private::Process’
CommandObjectCall.cpp:295: error: expected `;' before ‘return_status’
CommandObjectCall.cpp:299: error: ‘return_status’ was not declared in this scope
CommandObjectCall.cpp:302: error: ‘eExecutionSetupError’ is not a
member of ‘lldb_private::Process’
CommandObjectCall.cpp:308: error: ‘eExecutionCompleted’ is not a
member of ‘lldb_private::Process’
CommandObjectCall.cpp: At global scope:
CommandObjectCall.cpp:340: error: cannot convert ‘const char*’ to
‘lldb::CommandArgumentType’ in initialization
CommandObjectCall.cpp:340: error: cannot convert ‘const char*’ to
‘lldb::CommandArgumentType’ in initialization
CommandObjectCall.cpp:340: error: invalid conversion from ‘long int’
to ‘lldb::CommandArgumentType’
CommandObjectCall.cpp:340: error: cannot convert ‘const char*’ to
‘lldb::CommandArgumentType’ in initialization
CommandObjectCall.cpp:340: error: invalid conversion from ‘long int’
to ‘lldb::CommandArgumentType’
CommandObjectCall.cpp:340: error: invalid conversion from ‘long int’
to ‘lldb::CommandArgumentType’
make[2]: *** [/home/a/src/llvm-lldb_build/tools/lldb/source/Commands/Debug+Asserts/CommandObjectCall.o]
Error 1
make[2]: Leaving directory
`/home/a/src/llvm-lldb_build/tools/lldb/source/Commands'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/a/src/llvm-lldb_build/tools/lldb/source'
make: *** [all] Error 1

I am not so worried about the incorrect call to the CommandObjectCall
constructor, what perplexes me more is the errors for missing things
like 'eArgTypeType.'

As far as I can tell, eArgTypeType exists nowhere at all in the
source. I have used ack to search every file in the LLVM+LLDB tree,
and the only reference to it is in CommandObjectCall; I don't even see
a declaration of it anywhere.

Googling it, the only result is this lldb-commits post:

http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20101004/000910.html

which introduces the usage of those types as you can see in the diff,
but not their actual definitions. The same can be said of
eArgTypePlain and eArgTypeArgType as well I believe.

Is the current LLDB trunk build known to be broken, or are these
values expected to be defined somewhere else? Generated as part of the
build, perhaps (although that seems highly unlikely)?

Any help would be appreciated; I'd like to get LLDB building easily on
linux so it can be ported to work fully, eventually. I am currently
hosting my changes in a git repository (horray for git-svn) to keep
track of the changes in a more granular fashion, and it is on my
github:

https://github.com/thoughtpolice/lldb/commits/linux

All development happens on this 'linux' branch for me. You can see the
changes I've made in the above commit listing. But I would recommend
nobody check it out using git yet - because git svn must rebase when
updating the repository to reflect the latest SVN changes (it rebases
your un-pushed changes on top of all the new incoming SVN changes,)
the history will be rewritten frequently and I will have to
continuously delete and re-push my branch to github, if people want to
see it publicly, and if I want to keep up with the latest LLDB HEAD
revision (or I'll have to date the branches or something, but that
would be a PITA too.) As a result, anybody who pulls from it will have
to frequently delete their branch that tracks my 'linux' branch and
re-pull it, since it will be rebased fairly frequently to keep up with
HEAD when it changes. This isn't ideal, but it's better than managing
the changes with multiple .patch files, and through github it is
easier to see what changes I have made, and get comments on what
should/should not be done. If anybody can give some better tips on how
to manage this, that would be great, because I'm a git user and not
really a subversion person.

Regards,
Austin

Hi Austin,

austin seipp <as@hacks.yi.org> writes:

Hello,

I currently have spent a little bit of time in the past day or two
trying to get the latest copy of LLDB compiling on Linux.

I spent some time yesterday working on this. Hope to finish the work
soon.

[snip]

After having a built llvm+clang, and then attempting to build lldb, I
get into source/Breakpoints when this occurs:

llvm[2]: Compiling CommandObjectCall.cpp for Debug+Asserts build
In file included from CommandObjectCall.h:17,
                 from CommandObjectCall.cpp:10:

...

I am not so worried about the incorrect call to the CommandObjectCall
constructor, what perplexes me more is the errors for missing things
like 'eArgTypeType.'

Just delete CommandObjectCall.h and CommandObjectCall.cpp. They have
been unused in LLDB for some time.

Better to delete them then hack the build system to ignore the files.

[snip]

Is the current LLDB trunk build known to be broken, or are these
values expected to be defined somewhere else? Generated as part of the
build, perhaps (although that seems highly unlikely)?

My guess is that the XCode builds simply ignore those files.

Any help would be appreciated; I'd like to get LLDB building easily on
linux so it can be ported to work fully, eventually. I am currently
hosting my changes in a git repository (horray for git-svn) to keep
track of the changes in a more granular fashion, and it is on my
github:

https://github.com/thoughtpolice/lldb/commits/linux

I will look at your tree.

I have LLDB building on linux (but just building, there is even less
"functionality" then there was before the Linux support got out of
sync).

At the bottom of this message is the current diffstat for the changes I
have been working on. I need to cherry pick the changes that get the
tree to "just" build on linux and send them to the list. After that all
the other stuff to get the hundreds of warnigs cleaned up can go in.

I will look into publishing my own git tree later today or tommorow.

There really is not *that* much to do in order to get the tree to build
under linux :wink:

All development happens on this 'linux' branch for me. You can see the
changes I've made in the above commit listing. But I would recommend
nobody check it out using git yet - because git svn must rebase when
updating the repository to reflect the latest SVN changes (it rebases
your un-pushed changes on top of all the new incoming SVN changes,)
the history will be rewritten frequently and I will have to
continuously delete and re-push my branch to github, if people want to
see it publicly, and if I want to keep up with the latest LLDB HEAD
revision (or I'll have to date the branches or something, but that
would be a PITA too.) As a result, anybody who pulls from it will have
to frequently delete their branch that tracks my 'linux' branch and
re-pull it, since it will be rebased fairly frequently to keep up with
HEAD when it changes. This isn't ideal, but it's better than managing
the changes with multiple .patch files, and through github it is
easier to see what changes I have made, and get comments on what
should/should not be done. If anybody can give some better tips on how
to manage this, that would be great, because I'm a git user and not
really a subversion person.

If you use master to track the svn repo I would recommend that you do
not rebase your "linux" branch -- just update master using 'git svn
rebase' which should always be a simple fast-forward and pull those
changes into the "linux" branch using a merge commit. That way you have
a proper history that others using git can pull from while staying up to
date. Of course, you would need to manage any merge-conflicts, etc.

Take care,

Stephen,

Thank you for the follow-up, I figured I was not the only person
interested in this. re: the build issue, I assume the Makefiles on
linux just blindly compile all *.cpp files in the current directory,
whereas xcode project configurations will explicitly enumerate the
files that need to be built, so unused files are not a problem. I
assume nobody has used the makefiles for quite some time, so they've
fallen out of date (indeed, the commit logs say they have not been
touched for a while.)

Hopefully your changes can get merged soon. If you publish your git
repository before then (or after, if you plan on continuing working on
linux support,) please be sure to follow up with a URL so we could
collaborate in the future if you don't mind. I'd like to see LLDB on
Linux as I have gradually been moving all my personal code and
machines to Clang, and I do most of my development on Linux, not on OS
X. Once your changes are merged, more interesting things can be worked
on (and hopefully kept in sync with the tree.)

If you use master to track the svn repo I would recommend that you do
not rebase your "linux" branch -- just update master using 'git svn
rebase' which should always be a simple fast-forward and pull those
changes into the "linux" branch using a merge commit. That way you have
a proper history that others using git can pull from while staying up to
date. Of course, you would need to manage any merge-conflicts, etc.

This sounds like a much better idea and I can't believe I hadn't
thought of it, thanks.

Regards,
Austin

I removed the offending files for now, sorry about that. I need to get a some buildbots setup for both linux and darwin so we darwin folk know when we break the linux build.

Greg Clayton

Hi Austin,

austin seipp <as@hacks.yi.org> writes:

Stephen,

Thank you for the follow-up, I figured I was not the only person
interested in this. re: the build issue, I assume the Makefiles on
linux just blindly compile all *.cpp files in the current directory,
whereas xcode project configurations will explicitly enumerate the
files that need to be built, so unused files are not a problem. I
assume nobody has used the makefiles for quite some time, so they've
fallen out of date (indeed, the commit logs say they have not been
touched for a while.)

Hopefully your changes can get merged soon. If you publish your git
repository before then (or after, if you plan on continuing working on
linux support,) please be sure to follow up with a URL so we could
collaborate in the future if you don't mind. I'd like to see LLDB on
Linux as I have gradually been moving all my personal code and
machines to Clang, and I do most of my development on Linux, not on OS
X. Once your changes are merged, more interesting things can be worked
on (and hopefully kept in sync with the tree.)

I pushed the current state of my tree onto the lldb-linux branch here:

   https://github.com/eightcien/lldb/tree/lldb-linux

I have not thoroughly reviewed all of the changes myself -- but the tree
does build. Will be picking the critical commits out and sending them
to the list for review over the next few days (I hope).

I probably will not be looking at adding any features to the linux side
of things for a while -- just concentrate on getting the build working
and cleaning up as many compilation warnings as I can. Will keep the
github tree up to date as I work.

Take care,

Hi Greg,

Greg Clayton <gclayton@apple.com> writes:

I removed the offending files for now, sorry about that.

Thanks!

I need to get a some buildbots setup for both linux and darwin so we
darwin folk know when we break the linux build.

That would be absolutely excellent! It would make development on the
linux side so much simpler :slight_smile:

Thanks again,

Stephen,

I've replaced & forked your repository on github and have a change
that will let it LLDB compile under gcc 4.5. Also tested your branch
with this change on OS X snow leopard with xcodebuild.
Also I fixed a build failure for gcc 4.3 on my linux machine and
tested it w/ xcodebuild on OS X.

I'll also be putting warning cleanups and whatnot on my lldb-linux
branch. I suppose the easiest way would be for you to just pull them
(pull requests?) into your branch so they can be put into SVN trunk
soon. Git doesn't seem to track the git-svn metadata associated with
the original svn repository, since I am working from a clone of your
repository (since I want your changes,) so I can't easily 'svn rebase'
my master branch and then merge to update my trunk - I'm basically
left to tracking your repository at the moment. I'll have to figure
that one out until the svn trunk builds cleanly on linux.

Regards,
Austin

Austin,

austin seipp <as@hacks.yi.org> writes:

Stephen,

I've replaced & forked your repository on github and have a change
that will let it LLDB compile under gcc 4.5. Also tested your branch
with this change on OS X snow leopard with xcodebuild.

Very nice! It is *so* helpful to have these changes tested as I do not
have access ATM to a Darwin box.

Also I fixed a build failure for gcc 4.3 on my linux machine and
tested it w/ xcodebuild on OS X.

I pulled your changes. However, I am not too sure about turning off
warnings about VLA's.

The only point I see where a VLA is an issue is in ClangASTContext.cpp
(around line 1217). In this case, IMHO, it would be much better to use
an llvm::SmallVector instead.

I'll also be putting warning cleanups and whatnot on my lldb-linux
branch.

Great! I feel we need to get all the warnings out of the way before we
even think about supporting the wider LLDB infrastructure (aka "real"
functionality) on Linux.

I suppose the easiest way would be for you to just pull them
(pull requests?) into your branch so they can be put into SVN trunk
soon.

I will definitely submit a series of patches to the list for review that
at least gets LLDB to compile again on Linux. So pull requests are fine
and I will queue them up -- I am more than happy to review and post the
changes to the list.

But please do not think of me as a gatekeeper or any kind of authority.
If you send me a patch, that is cool. If you send one to the list and
it is accepted that is cool too -- I (and everyone else) will pick it
up.

Git doesn't seem to track the git-svn metadata associated with
the original svn repository, since I am working from a clone of your
repository (since I want your changes,) so I can't easily 'svn rebase'
my master branch and then merge to update my trunk - I'm basically
left to tracking your repository at the moment. I'll have to figure
that one out until the svn trunk builds cleanly on linux.

You _could_ just setup a tracking branch so that you do not depend on me
staying active. For example, if you have a "git svn clone" of the LLDB
repo then try (untested):

    #> git remote add steve git://github.com/eightcien/lldb.git
    #> git fetch steve
    #> git branch --track steve steve/lldb-linux

The above creates a local branch named "steve" that tracks my lldb-linux
branch on github (so if you have the "steve" branch checked out a "git
pull" will bring in the current changes I have published). That way
your master branch can stay in sync with LLDB's SVN server and you need
not care if I get hit by a bus :slight_smile:

However, I will try to stay more active in LLDB development than I have
in the past, so a clone might be just fine. Time will tell :wink:

Take care and thanks a lot!