>>>>> "gms" == Gerardo M Sarria M <[EMAIL PROTECTED]> writes:

  gms> * (load-foreign "/usr/lib/libPlayer.so")
  gms> ;;; Running /usr/bin/ld...
  gms> 
  gms> Error in function SYSTEM::LOAD-OBJECT-FILE:
  gms> Can't open object "/tmp/18501AG1300": NIL
  gms> [Condition of type SIMPLE-ERROR]

in the place of the NIL, you should be seeing an error message from
dlerror(), but it seems that dlerror isn't working very well.

The most likely explanation I can see for this is that your libPlayer
shared library was not built correctly, and contains external
dependencies that weren't correctly registered when it was built. I
don't have libPlayer on my machine, but I do have a faulty libgcj.so.2
that contains an unresolved reference.

,----
| % ldd /usr/lib/libgcj.so.2
|         libpthread.so.0 => /lib/libpthread.so.0 (0x403c1000)
|         libdl.so.2 => /lib/libdl.so.2 (0x40410000)
|         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40413000)
|         libc.so.6 => /lib/libc.so.6 (0x4041b000)
|         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
`----

If I try to load this library into CMUCL, with the environment
variable LD_DEBUG set to "symbols", I end up with

,----
|       2512:     symbol=_Jv_Jar_Class_Path;  lookup in file=/usr/lib/libgcj.so.2
|       2512:     symbol=GC_obj_kinds;  lookup in file=/opt/cmucl-latest-linux/bin/lisp
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/libdl.so.2
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/libm.so.6
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/libc.so.6
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/ld-linux.so.2
|       2512:     symbol=GC_obj_kinds;  lookup in file=/tmp/2512AG1642
|       2512:     symbol=GC_obj_kinds;  lookup in file=/usr/lib/libgcj.so.2
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/libc.so.6
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/libpthread.so.0
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/libdl.so.2
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/libgcc_s.so.1
|       2512:     symbol=GC_obj_kinds;  lookup in file=/lib/ld-linux.so.2
|       2512:     /usr/lib/libgcj.so.2: error: relocation error: undefined symbol: 
GC_obj_kinds (fatal)
|       2512:     calling fini: /tmp/2512AG1642
|       2512:     calling fini: /usr/lib/libgcj.so.2
|       2512:     calling fini: /lib/libgcc_s.so.1
|       2512:     symbol=component_ptr_from_pc;  lookup in 
file=/opt/cmucl-latest-linux/bin/lisp
| Error in function system::load-object-file:  Can't open object "/tmp/2512AG1642": nil
|    [Condition of type simple-error]
`----

>From a little detective work, I find out that the GC_obj_kinds symbol
is defined in libgcjgc. The libgcj doesn't have a dynamic dependency
on this library, so dlopen fails. However, if I specify this library
explicitly using the :libraries option to EXT:LOAD-FOREIGN, the
library loads ok (well, actually it starts segfaulting straight away,
because the two garbage collectors don't know about each other). 

I am guessing that the difference you are seeing between glibc
versions 2.2 and 2.3 is really from different versions of libPlayer on
the two machines. 
  
  
  gms> Why it search a file in /tmp ???

EXT:LOAD-FOREIGN uses an old-style interface to the system linker. It
starts by asking the linker (/usr/bin/ld) to convert the object file
into a format that can be loaded into the current process, possibly
resolving any dependencies in the object file from the list of
libraries passed (which defaults to libc). This produces a temporary
file, which is then loaded into the current process (using dlopen on
most modern systems).

Most applications that allow dynamic linking only support loading of
shared libraries (DSOs), via dlopen. The slightly tricky stuff that
CMUCL is doing allows it to load vanilla ".o" object files and ".a"
static libraries. This is at the expense of more fragility in the
loading mechanism.

-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>

Reply via email to