Steel Bank Common Lisp

SBCL complains about not finding vintage GLIBC_2.0 _h_errno in
/lib/libpthread.  However, lsof says that /lib/tls/libpthread-0.61.so
is being used instead.  It looks like lsof is wrong.  There is an
reference to _h_errno in the /lib version but not the /lib/tls
version.  The GLIBC_2.0 vintage errno does not exist in the
/lib/tls/libc-2.3.3 that lsof (if I can believe it) indicates is
active with SBCL.  However, it *is* defined in /lib/libc-2.3.3.so (and
/lib/libc.so.6 and /lib/i686/libc.so.6).

When I try to define LD_DEBUG so that I can track what is happening
(see, I actually tried to figure this out before I yelled for help),
then SBCL itself dies almost instantly, well before the error is
tickled.  I also looked in the sbcl sources (I have not built my own
-- yet), but didn't find anything that looked terribly relevant.

Is this a well-known phenomenon, with a well-known answer?
Any advice as to how to debug this?  Do I need to "preload" either the
/lib/tls pair of pthread & libc (or the /lib)?  Is this the Right
Thing To Do?

-jm

debugger invoked on a SIMPLE-ERROR in thread 32234:
  Could not open shared object #S(SB-ALIEN::SHARED-OBJECT
                                  :FILE "/lib/libpthread.so.0"
                                  :SAP NIL): /lib/libpthread.so.0: symbol 
_h_errno, version GLIBC_2.0 not defined in file libc.so.6 with link time 
reference

You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT   ] Reduce debugger level (leaving debugger, returning to 
toplevel).
  1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop.
("hairy arg processor for top level local call SB!SYS:DLOPEN-OR-LOSE"
 #S(SB-ALIEN::SHARED-OBJECT :FILE "/lib/libpthread.so.0" :SAP NIL))
0] :back

0: ("hairy arg processor for top level local call SB!SYS:DLOPEN-OR-LOSE"
    #S(SB-ALIEN::SHARED-OBJECT :FILE "/lib/libpthread.so.0" :SAP NIL))
1: (LOAD-SHARED-OBJECT 1 "/lib/libpthread.so.0")[:EXTERNAL]
2: (SB-INT:EVAL-IN-LEXENV
    2
    (LOAD-SHARED-OBJECT "/lib/libpthread.so.0")
    #S(SB-KERNEL:LEXENV
       :FUNS NIL
       :VARS NIL
       :BLOCKS NIL
       :TAGS NIL
       :TYPE-RESTRICTIONS NIL
       :LAMBDA NIL
       :CLEANUP NIL
       :HANDLED-CONDITIONS NIL
       :DISABLED-PACKAGE-LOCKS NIL
       :POLICY ((SPEED . 1) (SPACE . 1) (SAFETY . 1) (INHIBIT-WARNINGS . 1)
                (DEBUG . 1) (COMPILATION-SPEED . 1))))[:EXTERNAL]
3: (SB-FASL::LOAD-AS-SOURCE


-- 
==== John Morrison
==== MAK Technologies Inc.
==== 10 Fawcett Street, Cambridge, MA 02138
==== http://www.mak.com/
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== jm@...

On Tue, 17 May 2005, John Morrison wrote:

> LD_DEBUG death, I'm not so sure of yet, and I still cannot save a core
> image with my alien bindings in it, so I think there's Yet Another
> something screwy I'm doing.)

Which internal bits are you twiddling with? (As I've a vague recollection 
of pointing you towards some, I'm expecting this to be the case.)

Also, does this inability to save a core file manifest in not being able 
to save-lisp-and-die, or errors on startup? If the latter, a backtrace
from the error would be good.

As a totally unrelated thing, once you emerge victorious from these 
tribulations it would be very interesting to hear what all this has been 
for, and what SBCL (and other) hackery has been involved.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."