update: I tried the svn trunk (r14684) and building .CDB works without the EX_OSERR issue. Horray!<div><div><br></div><div>Is the trunk in a stable condition at r14684? I usually try to be a just little behind the bleeding edge. ;-)</div>
<div><br></div><div><div class="gmail_quote">On Sun, Mar 20, 2011 at 5:59 AM, Jason E. Aten <span dir="ltr"><<a href="mailto:j.e.aten@gmail.com">j.e.aten@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div>Arg. I'm so close to getting this working! Here I did an svn update to r14684 / r14469, and get an error in lib/compile-ccl.lisp about a 'Error: Foreign variable "EX_OSERR" not found'. I'll attach a full log with svn update details and a backtrace in case that helps.</div>
<div><br></div><div> - Jason</div><div><br></div><div>p.s. a couple of small things came up while I was trying to figure this out...</div><div><br></div><div><div>a. is there a way to show the source for a function already defined? In googling I found some notes about *recor\</div>
<div>d-source-file*, and CCL:*SAVE-SOURCE-LOCATIONS*, but I haven't figured out how to display the source for a functi\</div><div>on. Is that possible?</div><div><br></div><div>b. is there an option to automatically, upon error condition, go to the toplevel as if typing ctrl-d or :q, instead o\</div>
<div>f to the nested repl every time. I make alot of mistakes(!) and just want to try again immediately, without the e\</div><div>xtra keystroke of having to get out of the condition restart nested repl.</div><div><br></div>
</div><div>Thank you, thank you!</div><div><br></div><div>c. summary of attached log of svn update attempt:</div><div> </div><div>jaten@afarm:~/pkg/ccl$ ccl --no-init</div><div class="im"><div>trying: /home/jaten/pkg/ccl/lx86cl64</div>
<div>
Welcome to Clozure Common Lisp Version 1.6 (LinuxX8664)!</div></div><div>? (ccl:rebuild-ccl :full t)</div><div>Rebuilding Clozure Common Lisp using Version 1.6 (LinuxX8664)</div><div>;Building lisp-kernel ...</div><div>
;Kernel built successfully.</div>
<div>;Compiling "/home/jaten/pkg/ccl/lib/systems.lisp"...</div><div>;Loading #P"/home/jaten/pkg/ccl/bin/systems.lx64fsl"...</div><div>;Compiling "/home/jaten/pkg/ccl/lib/compile-ccl.lisp"...</div>
<div>Read error between positions 17010 and 17742 in /home/jaten/pkg/ccl/lib/compile-ccl.lisp.</div><div>> Error: Foreign variable "EX_OSERR" not found</div><div>> While executing: %LOAD-VAR, in process listener(1).</div>
<div class="im">
<div>> Type :POP to abort, :R for a list of available restarts.</div><div>> Type :? for other options.</div><div>1 > </div></div></div><div><br></div><div>#hmm... do I have the fix to lib/db-io.lisp ? It looks like it should be there from the svn log...</div>
<div><br></div><div><div>jaten@afarm:~/pkg/ccl/lib$ svn log db-io.lisp</div><div>------------------------------------------------------------------------</div><div>r14684 | gb | 2011-03-19 17:00:03 -0500 (Sat, 19 Mar 2011) | 2 lines</div>
<div><br></div><div>Propagate r14525 to 1.6 branch.</div></div><div><br></div><div># umph... I don't know what do try next!?!</div><div><div></div><div class="h5"><div><br></div><div><br></div><div class="gmail_quote">
On Sun, Mar 20, 2011 at 4:57 AM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That was fixed in the trunk a few months ago but the change hadn't<br>
been propagated to the 1.6 tree. It's there now.<div><br>
<br>
<br>
On Sat, 19 Mar 2011, Jason E. Aten wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>
Thank you for the fix on this, Gary.<br>
<br>
I tested it and it works. ?I can confirm that svn r72 of ffigen4 now works<br>
for me on?ccl/x86-headers64/libc/C/populate.sh ?under Ubunutu 10.04 on<br>
x86_64.<br>
<br>
I am still getting some kind of issue with the final assembly of .cdb files<br>
(they are not produced) during ENCODE-FFI-TYPE. ?I try to run<br>
cc::parse-standard-ffi-files on the resulting :libc, and I get this error:<br>
<br>
? (require "PARSE-FFI")<br>
"PARSE-FFI"<br>
("PARSE-FFI")<br>
? (ccl::parse-standard-ffi-files :libc)<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/_G_config.ffi" ...<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/a\\.out.ffi" ...<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/aio.ffi" ...<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/aliases.ffi" ...<br>
...<br>
...(all the .ffi files are listed and seem to load okay, and then)....<br>
...<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wchar.ffi" ...<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wctype.ffi" ...<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/wordexp.ffi" ...<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/xlocale.ffi" ...<br>
#P"/home/jaten/pkg/ccl/x86-headers64/libc/C/usr/include/zlib.ffi" ...<br>
> Error: value #<FFI-TRANSPARENT-UNION 286_/usr/include/wait.h<br>
#x302002F0059D> is not of the expected type FFI-UNION.<br>
> While executing: ENCODE-FFI-TYPE, in process listener(1).<br>
> Type :POP to abort, :R for a list of available restarts.<br>
> Type :? for other options.<br>
1 >?<br>
<br>
In case it helps diagnose this, I've attached copies of /usr/include/wait.h<br>
?and the ?~/pkg/ccl/x86-headers64/libc/C/usr/include/wait.ffi ?file<br>
generated by h-to-ffi.sh run under populate.sh with CFLAGS="-m64<br>
-D_GNU_SOURCE";export CFLAGS.<br>
<br>
Let me know if I can provide anything more.<br>
<br>
?- Jason<br>
<br>
<br>
On Sat, Mar 19, 2011 at 4:01 PM, Gary Byers <<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>> wrote:<br>
gcc-4.0.0 is several years old, but we (usually) don't care<br>
about that;<br>
what generally matters is that the gcc version in question<br>
follows the<br>
platform's ABI's rules about how structures are laid out and how<br>
their<br>
fields are aligned. ?Older GCC versions are generally easier to<br>
build<br>
(have fewer dependencies) than newer versions are, and on many<br>
platforms<br>
we can patch 4.0.0 and get a working translator; that's what the<br>
code<br>
in the ffigen4 svn trunk tries to do.<br>
<br>
The construct from /usr/include/bits/link.h that it's choking on<br>
(and<br>
it chokes for me as well, though I didn't notice) is the<br>
description<br>
of the (relatively new) 256-bit "ymm" vector register type.<br>
?ffigen<br>
doesn't believe that such a thing exists. ?It happens to be sort<br>
of<br>
right about that (it was supposed to have been introduced in<br>
Intel's<br>
"Sandy Bridge" chips, which got delayed/recalled and may or may<br>
not<br>
exist in shipping systems; I haven't followed it too closely)<br>
but the<br>
concept of 256-bit (and possibly larger) SIMD registers has been<br>
in<br>
some Linux headers (and kernels/libraries) for the last few<br>
years, and<br>
we need to support that.<br>
<br>
I checked in a change to ffigen that seems to fix this.<br>
<br>
On Sat, 19 Mar 2011, Jason E. Aten wrote:<br>
<br>
Hmm... that does indeed look like the wiki page I was<br>
referencing. ?Is<br>
gcc-4.0.0 not the current version?<br>
Here's the exact script (with sequence of commands) that I<br>
wrote to preserve<br>
exactly how I went about acquiring and installing ffigen<br>
and h-to-ffi.sh. If<br>
you have trouble reproducing it, let me know. It's just a<br>
stock Ubuntu 10.04<br>
on x86_64, but I can give you a login on a remote box if<br>
need be, or get you<br>
a virtualbox image.<br>
Thanks,<br>
Jason<br>
<br>
jaten@AtenMBP-2:~/research/djitia$ cat install-ffigen.sh?<br>
#!/bin/bash<br>
svn co<br>
<a href="http://svn.clozure.com/publicsvn/ffigen4/trunk/ffigen4" target="_blank">http://svn.clozure.com/publicsvn/ffigen4/trunk/ffigen4</a><br>
cd ffigen4/<br>
wget<br>
<a href="http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-core-4.0.0.tar.bz2" target="_blank">http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-core-4.0.0.tar.bz2</a><br>
wget<br>
<a href="http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-objc-4.0.0.tar.bz2" target="_blank">http://ftp.gnu.org/gnu/gcc/gcc-4.0.0/gcc-objc-4.0.0.tar.bz2</a><br>
make<br></div></div>
# example sudo tarxfz/home/jaten/pkg/llvm28/llvm-2.8/tools/ldc2/ffigen/ffigen4/ffigen-bin-lin<div><div></div><div><br>
uxx<br>
8664-gcc-4.0.0-2011-03-18-23-40-54.tar.gz -C /usr/local<br>
export TARBALL=`ls -1 | grep ffigen-bin`<br>
export HERE=`pwd`<br>
<br>
echo "installing now to: ? ?/usr/local/ffigen ? and ?<br>
/usr/local/bin/h-to-ffi.sh ? ...with sudo"<br>
echo "sudo tar xfz `pwd`/`ls -1 | grep ffigen-bin` -C<br>
/usr/local"<br>
sudo tar xfz `pwd`/`ls -1 | grep ffigen-bin` -C /usr/local<br>
<br>
<br>
On Sat, Mar 19, 2011 at 11:37 AM, Gary Byers<br>
<<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>> wrote:<br>
? ? ?Hmm. ?The Wiki page at<br>
? ? ?<<a href="http://trac.clozure.com/ccl/wiki/BuildFFIGEN" target="_blank">http://trac.clozure.com/ccl/wiki/BuildFFIGEN</a>> is<br>
? ? ?supposed to be the canonical reference that describes<br>
how to<br>
? ? ?obtain/build/install<br>
? ? ?the FFI translator. ?In the past, we've distributed<br>
sources and<br>
? ? ?binaries via<br>
? ? ?other means, but there aren't supposed to be any<br>
links to those<br>
? ? ?older versions<br>
? ? ?and I can't find any links in the documentation.<br>
<br>
? ? ?The current version doesn't have any problem<br>
translating<br>
? ? ?/usr/include/link.h<br>
? ? ?(or with the SIMD vector type referenced in the<br>
included file),<br>
? ? ?but I'd certainly<br>
? ? ?believe that older versions did. ?If you got an older<br>
version,<br>
? ? ?that'd explain<br>
? ? ?it; if you remember how you got that version, we<br>
should fix any<br>
? ? ?links to it<br>
? ? ?so that they reference the Wiki page instead.<br>
<br>
? ? ?On Sat, 19 Mar 2011, Jason E. Aten wrote:<br>
<br>
? ? ?Thank you Raffael. ?I appreciate the pointer. I guess<br>
that<br>
? ? ?confirms #1, and<br>
? ? ?answers #2. :-)<br>
<br>
? ? ?For #3, I've managed to locate the source code for<br>
the<br>
? ? ?ffigen loader, and<br>
? ? ?figured out that :SUBDIR is supposed to be :libc or<br>
:elf<br>
? ? ??or similar.<br>
<br>
? ? ?However I do manage to have populate.sh run into an<br>
issue:<br>
<br>
? ? ?+++ /usr/include/link.h<br>
? ? ?Need to create info for type:<br>
? ? ??<vector_type 0x7fab52eacb60<br>
? ? ??? ?type <real_type 0x7fab53619000 float SF<br>
? ? ??? ? ? ?size <integer_cst 0x7fab535fba80 constant<br>
? ? ?invariant 32><br>
? ? ??? ? ? ?unit size <integer_cst 0x7fab535fb5a0<br>
constant<br>
? ? ?invariant 4><br>
? ? ??? ? ? ?align 32 symtab 18 alias set -1 precision 32<br>
? ? ??? ? ? ?pointer_to_this <pointer_type<br>
0x7fab53619270>><br>
? ? ??? ?BLK<br>
? ? ??? ?size <integer_cst 0x7fab536146f0 type<br>
<integer_type<br>
? ? ?0x7fab536015b0<br>
? ? ?bit_size_type> constant invariant 256><br>
? ? ??? ?unit size <integer_cst 0x7fab535fb570 type<br>
? ? ?<integer_type 0x7fab536014e0<br>
? ? ?long unsigned int> constant invariant 32><br>
? ? ??? ?align 256 symtab 341 alias set -1 nunits 8><br>
? ? ?In file included from /usr/include/link.h:36:<br>
? ? ?/usr/include/bits/link.h:68: internal compiler error:<br>
in<br>
? ? ?ffi_create_type_info, at ffi.c:428<br>
? ? ?Please submit a full bug report,<br>
? ? ?with preprocessed source if appropriate.<br>
? ? ?See <URL:<a href="http://gcc.gnu.org/bugs.html" target="_blank">http://gcc.gnu.org/bugs.html</a>> for<br>
instructions.<br>
<br>
? ? ?where the relevant section from<br>
/usr/include/bits/link.h,<br>
? ? ?including line 68<br>
? ? ?is this:<br>
<br>
? ? ?/* Registers for entry into PLT on x86-64. ?*/<br>
? ? ?# if __GNUC_PREREQ (4,0)<br>
? ? ?typedef float La_x86_64_xmm __attribute__<br>
? ? ?((__vector_size__ (16)));<br>
? ? ?typedef float La_x86_64_ymm __attribute__<br>
? ? ?((__vector_size__ (32))); ?/* line<br>
? ? ?68 */<br>
? ? ?# else<br>
? ? ?typedef float La_x86_64_xmm __attribute__ ((__mode__<br>
? ? ?(__V4SF__)));<br>
? ? ?# endif<br>
<br>
? ? ?Arg. What should I try? ?Is this the right place to<br>
report<br>
? ? ?this?<br>
<br>
? ? ?Thank you.<br>
<br>
? ? ?Jason<br>
<br>
<br>
? ? ?On Sat, Mar 19, 2011 at 12:21 AM, Raffael Cavallaro<br>
? ? ?<<a href="mailto:raffaelcavallaro@mac.com" target="_blank">raffaelcavallaro@mac.com</a>> wrote:<br>
<br>
? ? ?? ? ?On Mar 19, 2011, at 1:09 AM, Jason E. Aten<br>
wrote:<br>
<br>
? ? ?? ? ?> In order words, when two different threads<br>
need to<br>
? ? ?be able to<br>
? ? ?? ? ?name the same variable (after locking the thread<br>
? ? ?inspects the<br>
? ? ?? ? ?shared variable, possibly updates it, then<br>
releases<br>
? ? ?the lock),<br>
? ? ?? ? ?how do I tell lisp this is what I'd like?<br>
<br>
? ? ?See section 4.8 of the documentation "Static<br>
Variables"<br>
<br>
? ? ?e.g., (defstatic *foo* 3)<br>
<br>
? ? ?It's an error to dynamically rebind a static<br>
variable; its<br>
? ? ?value is<br>
? ? ?always the same across all threads. Naturally, as you<br>
? ? ?suggest, you'll<br>
? ? ?want to avoid race conditions by using a lock or<br>
? ? ?semaphore.<br>
<br>
? ? ?warmest regards,<br>
<br>
? ? ?Ralph<br>
<br>
<br>
? ? ?Raffael Cavallaro<br>
? ? ?<a href="mailto:raffaelcavallaro@me.com" target="_blank">raffaelcavallaro@me.com</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Jason E. Aten, Ph.D.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Jason E. Aten, Ph.D.<br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
</blockquote></div><br><br clear="all"><br></div></div>-- <br><div><div></div><div class="h5">Jason E. Aten, Ph.D.<br><br><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jason E. Aten, Ph.D.<br><br><br>
</div></div>