#634 (require "linux") fails on undefined symbol rpl_ioctl

lisp error
open
Bruno Haible
modules (18)
5
2012-03-27
2012-03-27
No

On gentoo:

$ uname -a
Linux kuiper 2.6.38-gentoo-r6-pjb-c9 #2 SMP Wed Jul 13 00:23:08 CEST 2011 x86_64 Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz GenuineIntel GNU/Linux

I cannot load the linux module, because of some undefined symbol:

TEST> (lisp-implementation-version)
"2.49+ (2010-07-17) (built 3541129397) (memory 3541129660)"
TEST> (require "linux")
;; Loading file /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/linux.lisp ...
;; Loading module linux from /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so

*** - SYSTEM::DYNLOAD-MODULES: "dlopen" -> "/data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so: undefined symbol: rpl_ioctl"
The following restarts are available:
SKIP :R1 skip (DYNLOAD-MODULES # '#)
RETRY :R2 retry (DYNLOAD-MODULES # '#)
STOP :R3 stop loading file /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/linux.lisp
RETRY :R4 Retry SLIME REPL evaluation request.
PROCESS-INPUT :R5 Continue reading input.
ABORT :R6 Return to SLIME's top level.
CLOSE-CONNECTION :R7 Close SLIME connection.
ABORT :R8 Abort main loop
C/Break 1 COM.INFORMATIMAGO.RUN-PROGRAM.TEST[2]> :bt

Indeed, there's a reference to rpl_ioctl in lib-linux.so:
[pjb@kuiper :0 tmp]$ nm /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so|grep rpl
U rpl_ioctl
[pjb@kuiper :0 tmp]$ ldd /data/languages/clisp-hg/lib/clisp-2.49+/dynmod/lib-linux.so
linux-vdso.so.1 => (0x00007fff269ff000)
libm.so.6 => /lib/libm.so.6 (0x00007f9738b13000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f97388f5000)
libc.so.6 => /lib/libc.so.6 (0x00007f973858f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9738fa2000)

But I can't find it in those libraries.

[pjb@kuiper :0 tmp]$ nm /lib64/ld-linux-x86-64.so.2 | grep rpl
nm: /lib64/ld-linux-x86-64.so.2: no symbols
[pjb@kuiper :0 tmp]$ nm /lib/libc.so.6 | grep rpl
nm: /lib/libc.so.6: no symbols

Sam says:

rpl_* come from gnulib, so it is in libgnu.a;
libgnu.a is linked into lisp.run
(all of them: boot, base, and full, so "clisp -K full" works);
but since rpl_ioctl is not used by base,
it is dropped from base/lisp.run;
so when you try to load lib-linux.so which uses rpl_ioctl, it fails.

This patch fixes the error, but I don't like the solution because it means that
every module which uses rpl_ioctl will come with its own implementation.

A better solution is welcome.

Discussion

  • Sam Steingold
    Sam Steingold
    2012-03-27

    at least rawsock needs a similar patch to fix require.
    a better approach is necessary.

     
  • Sam Steingold
    Sam Steingold
    2012-03-27

    bindings/glibc & rawsock workaround

     
    Attachments
  • Sam Steingold
    Sam Steingold
    2012-04-18

    on linux my patch increases the sizes of dynamic libraries by less than 1%:

    lib-linux.so: 138882 --> 139965
    lib-rawsock.so: 265699 --> 266758

    I guess this is not such a big deal on linux, but on other platforms,
    where libgnu is basically glibc in disguise,
    linking it in twice may not me such a good idea.

    I think it would be great if you could complain to bug-gnulib@gnu.org
    about the lack of libgnu.so, see
    http://article.gmane.org/gmane.comp.lib.gnulib.bugs:27753