On Thu, Jul 1, 2010 at 3:33 AM, Pascal J. Bourguignon <pjb@informatimago.com> wrote:

I get this error when asdf loading  :usocket.
[pjb@kuiper :0.0 site]$ ls -ld /tmp
drwxrwxrwt 9 root root 36864 Jul  1 03:18 /tmp/
What could be the cause?

ECL has to have the ability to load the same FASL file multiple times. Furthermore, these files must be deletable as the user may wish to overwrite them at any time. None of these requirements works with an implementation that relies on the operating system to load binaries.  Some reasons are
* Binary file write permissions may be disabled when the file is loaded.
* The operating system may refuse to load a binary file with the same name as one that was already loaded.
* If the file is overwritten, some operating systems still refuse to load it again.
...
The list is uncountable :-) After a lot of consideration the only solution I found is to perform a copy of each FASL file before LOADing it. Thus

LOAD
-> ecl_library_open
 -> copy_object_file
  -> si_copy_file
 -> dlopen

At some point your OS seems to be refusing _also_ that the FASL file be copied, which is kind of weird. I hope this will help you find out what is the problem -- here usocket loads just fine :-/
 
Also, is this something of slime or of ECL not to print the whole
pathnames?  I've got *print-length* set to NIL, etc though...

Probably Slime's debugger sets *print-length* or uses some custom printing format.

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com