[ clisp-Bugs-3512035 ] (require "linux") fails on undefined symbol rpl_ioctl

Bugs item #3512035, was opened at 2012-03-27 10:36
Message generated for change (Comment added) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3512035&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: (require "linux") fails on undefined symbol rpl_ioctl 

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Sam Steingold (sds)
Date: 2012-04-18 15:18

Message:
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  [email protected]
about the lack of libgnu.so, see
http://article.gmane.org/gmane.comp.lib.gnulib.bugs:27753

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2012-03-27 11:15

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3512035&group_id=1355

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel