[LLVMdev] Adding system libraries to the LLVM build
reid at x10sys.com
Fri Mar 18 22:57:42 CST 2005
If the JIT stuff is now capable of being multi-threaded then we need to
update the libraries that "LLVMLIBS := JIT" pulls in to include
-lpthread. There are definite "correct" ways to do this in the configure
and makefile system. If you open a PR for this work (I don't know if its
still needed based on the discussion below) and assign it to me, I'll
fix it fairly quickly.
On Wed, 2005-03-16 at 18:19, Evan Jones wrote:
> On Mar 16, 2005, at 12:01, Chris Lattner wrote:
> > 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.
> Well, at the moment, I've added a mutex to ExecutionEngine. Thus,
> anything that pulls in this class needs thread support. After using
> grep, it seems like the only thing besides the JIT is the interpreter.
> Linking all the llvm tools with pthreads would be overkill, but it
> certainly won't hurt too much, except wasting a bit of virtual memory.
> At any rate, I've got a hack now that works, and I'll worry about the
> exact details a bit later (or maybe let someone else worry about the
> exact details later?).
> > In particular, I don't know the appropriate way to autoconf this,
> > though I'm sure there is some standard way to do it.
> Right. I've found a couple of pthreads autoconf macros but the systems
> I have access to all have autoconf 2.57, not 2.59. Ergh. I'm not going
> to worry about autoconf for now, but I'll see if I can find a more up
> to date.
> > 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 about it.
> Hmm... I can see that might be a bit of a challenge, particularly if
> the interpreter can call out to native code, and be called by native
> code. It would definitely involve using thread local storage for the
> per thread interpreter state. I'm definitely not going to worry about
> that, but it certainly does mean that I won't feel bad pulling in
> pthreads as a dependency.
> Evan Jones
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.cs.uiuc.edu/pipermail/llvmdev/attachments/20050318/b67b277c/attachment.bin
More information about the LLVMdev