<div>Thank you Raffael.  I appreciate the pointer. I guess that confirms #1, and answers #2. :-)</div><div><br></div><div>For #3, I've managed to locate the source code for the ffigen loader, and figured out that :SUBDIR is supposed to be :libc or :elf  or similar.</div>
<div><br></div><div>However I do manage to have populate.sh run into an issue:</div><div><br></div><div><div>+++ /usr/include/link.h</div><div>Need to create info for type:</div><div> <vector_type 0x7fab52eacb60</div><div>
    type <real_type 0x7fab53619000 float SF</div><div>        size <integer_cst 0x7fab535fba80 constant invariant 32></div><div>        unit size <integer_cst 0x7fab535fb5a0 constant invariant 4></div><div>
        align 32 symtab 18 alias set -1 precision 32</div><div>        pointer_to_this <pointer_type 0x7fab53619270>></div><div>    BLK</div><div>    size <integer_cst 0x7fab536146f0 type <integer_type 0x7fab536015b0 bit_size_type> constant invariant 256></div>
<div>    unit size <integer_cst 0x7fab535fb570 type <integer_type 0x7fab536014e0 long unsigned int> constant invariant 32></div><div>    align 256 symtab 341 alias set -1 nunits 8></div><div>In file included from /usr/include/link.h:36:</div>
<div>/usr/include/bits/link.h:68: internal compiler error: in ffi_create_type_info, at ffi.c:428</div><div>Please submit a full bug report,</div><div>with preprocessed source if appropriate.</div><div>See <URL:<a href="http://gcc.gnu.org/bugs.html">http://gcc.gnu.org/bugs.html</a>> for instructions.</div>
<div><br></div><div>where the relevant section from /usr/include/bits/link.h, including line 68 is this:</div><div><br></div><div><div>/* Registers for entry into PLT on x86-64.  */</div><div># if __GNUC_PREREQ (4,0)</div>
<div>typedef float La_x86_64_xmm __attribute__ ((__vector_size__ (16)));</div><div>typedef float La_x86_64_ymm __attribute__ ((__vector_size__ (32)));  /* line 68 */</div><div># else</div><div>typedef float La_x86_64_xmm __attribute__ ((__mode__ (__V4SF__)));</div>
<div># endif</div><div><br></div><div>Arg. What should I try?  Is this the right place to report this?</div><div><br></div><div>Thank you.</div><div><br></div><div>Jason</div></div><div><br></div></div><br><div class="gmail_quote">
On Sat, Mar 19, 2011 at 12:21 AM, Raffael Cavallaro <span dir="ltr"><<a href="mailto:raffaelcavallaro@mac.com">raffaelcavallaro@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Mar 19, 2011, at 1:09 AM, Jason E. Aten wrote:<br>
<br>
> In order words, when two different threads need to be able to name the same variable (after locking the thread inspects the shared variable, possibly updates it, then releases the lock), how do I tell lisp this is what I'd like?<br>

<br>
</div>See section 4.8 of the documentation "Static Variables"<br>
<br>
e.g., (defstatic *foo* 3)<br>
<br>
It's an error to dynamically rebind a static variable; its value is always the same across all threads. Naturally, as you suggest, you'll want to avoid race conditions by using a lock or semaphore.<br>
<br>
warmest regards,<br>
<br>
Ralph<br>
<br>
<br>
Raffael Cavallaro<br>
<a href="mailto:raffaelcavallaro@me.com">raffaelcavallaro@me.com</a><br>
<br><br></blockquote></div>