[LLVMdev] Adding system libraries to the LLVM build

Reid Spencer reid at x10sys.com
Fri Mar 18 20:57:42 PST 2005


Evan,

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.

Reid.

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
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050318/b67b277c/attachment.sig>


More information about the llvm-dev mailing list