From: Sam S. <sd...@gn...> - 2004-08-31 15:28:08
|
now that we have (:LIBRARY :DEFAULT) for DEF-CALL-OUT and DEF-C-VAR, shouldn't we discard register_foreign_variable() and register_foreign_function() and make (:LIBRARY :DEFAULT) the default? -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Oh Lord, give me the source code of the Universe and a good debugger! |
From: Bruno H. <br...@cl...> - 2004-08-31 17:42:33
|
Sam wrote: > now that we have (:LIBRARY :DEFAULT) for DEF-CALL-OUT and DEF-C-VAR, > shouldn't we discard register_foreign_variable() and > register_foreign_function() and make (:LIBRARY :DEFAULT) the default? How portable is RTLD_DEFAULT? 1) RTLD_DEFAULT works only with dlopen(). libltdl is the portable alternative to dlopen(); it works even with static libraries. I would suggest to use libltdl in preferrence of dlopen() when available. libtool-1.9b's NEWS file says that it should work better on Windows now. Does libltdl support the equivalent of RTLD_DEFAULT portably? 2) RTLD_DEFAULT is defined in <dlfcn.h> only if #ifdef __USE_GNU. What does this mean? Is RTLD_DEFAULT part of POSIX or not? 3) Does the glibc RTLD_DEFAULT work with stripped binaries? register_foreign_variable() and register_foreign_function() are fully portable. Bruno |
From: Sam S. <sd...@gn...> - 2004-08-31 21:13:07
|
> * Bruno Haible <oe...@py...t> [2004-08-31 19:39:08 +0200]: > > Sam wrote: >> now that we have (:LIBRARY :DEFAULT) for DEF-CALL-OUT and DEF-C-VAR, >> shouldn't we discard register_foreign_variable() and >> register_foreign_function() and make (:LIBRARY :DEFAULT) the default? > > How portable is RTLD_DEFAULT? how portable is dlsym? > 1) RTLD_DEFAULT works only with dlopen(). libltdl is the portable > alternative to dlopen(); it works even with static libraries. I would > suggest to use libltdl in preferrence of dlopen() when > available. libtool-1.9b's NEWS file says that it should work better on > Windows now. > > Does libltdl support the equivalent of RTLD_DEFAULT portably? it appears that lt_dlforeach() and lt_dlhandle_next() offer functionality equivalent to RTLD_DEFAULT and RTLD_NEXT. i.e., they can be used to implement :DEFAULT similar to win32. > 2) RTLD_DEFAULT is defined in <dlfcn.h> only if #ifdef __USE_GNU. What > does this mean? dunno. > Is RTLD_DEFAULT part of POSIX or not? yes. <http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html> > 3) Does the glibc RTLD_DEFAULT work with stripped binaries? of course, why not? (nm works, right?) > register_foreign_variable() and register_foreign_function() are fully > portable. but very limited: to use a function, you must take care of it at link time. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Never trust a man who can count to 1024 on his fingers. |
From: Bruno H. <br...@cl...> - 2004-09-01 12:13:22
|
Sam wrote: > > How portable is RTLD_DEFAULT? > > how portable is dlsym? dlsym: only platforms with dlopen(). Not AIX 4. Not HP-UX. Maybe not MacOS X. Not Woe32. > > 1) RTLD_DEFAULT works only with dlopen(). libltdl is the portable > > alternative to dlopen(); it works even with static libraries. I would > > suggest to use libltdl in preferrence of dlopen() when > > available. libtool-1.9b's NEWS file says that it should work better on > > Windows now. > > > > Does libltdl support the equivalent of RTLD_DEFAULT portably? > > it appears that lt_dlforeach() and lt_dlhandle_next() offer > functionality equivalent to RTLD_DEFAULT and RTLD_NEXT. > i.e., they can be used to implement :DEFAULT similar to win32. Good, then let's use libltdl where possible. > > 2) RTLD_DEFAULT is defined in <dlfcn.h> only if #ifdef __USE_GNU. What > > does this mean? > > dunno. > > > Is RTLD_DEFAULT part of POSIX or not? > > yes. > <http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html> Actually, it's not part of POSIX. It's described there as "reserved for future use". That's also likely the reason why it's not defined by default in glibc's <dlfcn.h>. > > 3) Does the glibc RTLD_DEFAULT work with stripped binaries? > > of course, why not? > (nm works, right?) On a stripped binary, - "nm" shows no symbols, - "nm --dynamic" shows some few global variables only. So you must assume that RTLD_DEFAULT does not work on stripped binaries. Whereas register_foreign_variable() and register_foreign_function() do. > > register_foreign_variable() and register_foreign_function() are fully > > portable. > > but very limited: to use a function, you must take care of it at link > time. Which is why I designed the FFI in such a way that the compiler generates register_foreign_variable() and register_foreign_function() calls! Summarizing: You are trying to change the general FFI approach of clisp. While some other Lisps use dlopen(), dlsym(), and therefore - don't work on some platforms, - don't work with static libraries, - don't work with stripped binaries, I designed the current FFI to work portably; the only limitation is that avcall/callback must be supported. The situation regarding OS support of dynamic loading has not changed much since 1995. The only thing that changed is the advent of libltdl, which will make it work on all platforms and with static libraries. With stripped binaries? I'm not sure. You want a more dynamic FFI? So please add a libltdl based facility as an _alternative_ of the current one, and then only, after it has been verified that libltdl works without restrictions and with stripped binaries, _then_ only you can remove the register_foreign_variable() and register_foreign_function() and associated compiler support. Bruno |
From: Sam S. <sd...@gn...> - 2004-09-01 13:02:39
|
> * Bruno Haible <oe...@py...t> [2004-09-01 14:09:40 +0200]: > > Sam wrote: >> > How portable is RTLD_DEFAULT? >> >> how portable is dlsym? > > dlsym: only platforms with dlopen(). Not AIX 4. Not HP-UX. Maybe not > MacOS X. does ltdl work on all these platforms? do we need to distribute ltdl with CLISP? > Not Woe32. I implemented a similar functionality on win32. >> > 3) Does the glibc RTLD_DEFAULT work with stripped binaries? >> >> of course, why not? >> (nm works, right?) > > On a stripped binary, > - "nm" shows no symbols, > - "nm --dynamic" shows some few global variables only. > So you must assume that RTLD_DEFAULT does not work on stripped binaries. no. malloc _is_ found in /lib/libc.so even though it is obviously stripped. if dlsym() works on a stripped lib, then RTLD_DEFAULT will too. RTLD_DEFAULT is just repeated dlsym! -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Type louder, please. |