[LLVMdev] Adding system libraries to the LLVM build
sabre at nondot.org
Wed Mar 16 09:01:34 PST 2005
On Tue, 15 Mar 2005, Evan Jones wrote:
> I'm back working on my threading patch for the LLVM JIT after being
> distracted by a paper deadline. I think I have things working nicely on Mac
> OS X (I just did a CVS up and it will take another hour or two to build), but
> I'm having an issue with building on Linux. Specifically, "lli" fails to link
> because it now needs to link against libpthread, because it ends up pulling
> in ExecutionEngine.h which in turn pulls in ThreadSupport.h. I'm wondering
> how this should be fixed, because I'm afraid it may not be a simple problem.
> So the first question is, to which Makefile do I need to add the "-lpthread"
> flag to get the thing to compile? The next issue is what is the *right* way
> to do this:
I think the answer is some form of:
1. The platform specific flag (e.g. -lpthread) should go into
Makefile.config, named something like THREADS_LINKOPTS. This should
obviously be autoconf'd.
2. In Makefile.rules at about line 800, we handle linking tools that use
the JIT. This would be a natural place to add THREADS_LINKOPTS to the
link arguments (e.g. like "-dlopen self" is added).
It's not clear to me if pthreads will be required just by the
JIT-using-tools, or if it will be required by everything. If you have
thread-support stuff going into lib/Support, all llvm tools should be
linked to libpthread.
With all of the above said, I'm no longer the llvm build system guru, so
I'll defer to Reid to make any comments and corrections on the above
advice. :) In particular, I don't know the appropriate way to autoconf
this, though I'm sure there is some standard way to do it.
> 2. The interpreter probably does not need thread support at all, since it is
> almost certainly thread unsafe. Maybe it should override the "platform"
> version of ThreadSupport and with a null implementation. Alternatively,
> perhaps ExecutionEngine.h should not pull in ThreadSupport, and only JIT.h
I think that ideally eventually the interpreter should support threads as
well, but it's not worth actually doing the work now, so I wouldn't worry
More information about the llvm-dev