From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user Subject: Re: updated $workbook/modules/modules-and-shared-libs.text Date: 22 May 2002 14:28:38 +0200 Sender: guile-user-admin@gnu.org Message-ID: <87n0us74eh.fsf@zagadka.ping.de> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1022070644 3043 127.0.0.1 (22 May 2002 12:30:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 22 May 2002 12:30:44 +0000 (UTC) Cc: guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17AVGO-0000my-00 for ; Wed, 22 May 2002 14:30:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17AVFu-0006sL-00; Wed, 22 May 2002 08:30:14 -0400 Original-Received: from dialin.speedway42.dip162.dokom.de ([195.138.42.162] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17AVEO-0006l1-00 for ; Wed, 22 May 2002 08:28:40 -0400 Original-Received: (qmail 1404 invoked by uid 1000); 22 May 2002 12:28:38 -0000 Original-To: ttn@glug.org In-Reply-To: Original-Lines: 97 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:474 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:474 Thien-Thi Nguyen writes: > i've added some comments. me too. Woohoo, discussion via CVS... The following is by mvo, w/ editorial comments by by others. The latter can be identified by "[NAME: ....]". _________________________________________________________________ Guile used to be able to automatically find and link a shared library to satisfy requests for a module. For example, the module `(foo bar)' could be implemented by placing a shared library named "foo/libbar.so" (or with a different extension) in a directory on the load path of Guile. This has been found to be too tricky, and is no longer supported. The shared libraries are now called "extensions". You should now write a small Scheme file that calls `load-extension' to load the shared library and initialize it explicitely. [ttn: This decision to drop support applies to guile-1.6.x; guile-1.4.x continues to support this.] [mvo: However, it is not clear yet that there will be a 1.4.x series.] Here is more about why "this has been found to be to tricky". It is about the way it was done, not about why it can't possible at all. While this support was still present, modules could be either implemented by Scheme source files, or by shared libraries compiled from C. These two forms are two very different things: one is platform independent and installed somewhere in 'prefix', the other is platform dependent and is installed in 'exec-prefix'. However, Guile had no platform dependent locations in its default search path. Moreover, the search algorithm required shared libraries that were to be autoloaded as modules to reside not in the usual library directories (like /usr/local/lib), but in Guile search path as .../foo/libbar.so for example for module (foo bar). This will not really work for shared libraries that are also to be used from C code. Guile usually provides a C API for its features that are written in C. This should be encouraged for extensions as well. However, the Unix shared library does not deal well with shared libraries that don't come from standard locations or are referenced by multiple names (symlinks). [ttn: Guile uses libtool and consequently libltdl, so it is possible to use `lt_dlsetsearchpath' to alleviate (and actually bypass) OS restrictions. A scheme binding for `lt_dlsetsearchpath' is also possible. Thus, this argument against guile-1.4.x system actually can be recast as an argument for providing access and appropriate supporting protocol to `lt_dlsetsearchpath'.] [mvo: Whatever additional tricks libltdl does, they do not apply to ld or ld.so. Shared libraries are not only used at run-time (via lt_dlopen, say), but also at link-time (by ld) and load-time (by ld.so, or whatsitcalledonyourplatform). It might very well be possible to design something that is more advanced than 'load-extension' and plays well with lt_dlopen, ld, and ld.so, but limiting us to the very simple things that 'load-extension' does now gives us (at least, me) good confidence that it will work fairly portably.] Additionally, module boundaries are not necessarily language boundaries. That is, a module can be a mix of Scheme and C (and one file might want to provide more than one module). Therefore, we need a good way to load shared libraries independently from modules anyway. [ttn: In dynl.c there are several good ways already. The guile-1.6.x `load-extension' doesn't seem to be very much value-add over the already provided and stable mechanisms. There is no spec for it, including failure modes. There are plans to change its interface incompatibly. Its registry is opaque (and redundant).] [mvo: It is deliberate that 'load-extension' adds very little over dynamic-link/dynamic-call. I don't know of any plans to change its interface incompatibly. You can ignore the registry. It is there for people who want to statically link extensions.] Restricting module system operations and autoloading to Scheme code only provided an immediate and significant simplification, without much hassle to the user. The simplified setup should also be easier to understand. [ttn: The "without much hassle" is unfounded, unfortunately. The guile-1.4.x system supports C++ encapsulation of a "module" as a C++ object, and two-phase protocol for use: registration before libguile is initialized, and then run-time loading as described above. Registry manipulation is supported. None of this is available w/ guile-1.6.x if configured w/ the "--disable-deprecated" option. None of this is available in HEAD at this time (2002-05-21).] [mvo: Yes, "much hassle" is a subjective term. But there are no complaints (besides yours) about it.] _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user