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: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: 14 Apr 2002 23:30:52 +0200 Sender: guile-user-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018819930 16863 127.0.0.1 (14 Apr 2002 21:32:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 14 Apr 2002 21:32:10 +0000 (UTC) Cc: ttn@glug.org, guile-devel@gnu.org, 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 16wrbW-0004Ns-00 for ; Sun, 14 Apr 2002 23:32:10 +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 16wrZg-0002cP-00; Sun, 14 Apr 2002 17:30:16 -0400 Original-Received: from dialin.speedway42.dip177.dokom.de ([195.138.42.177] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16wrXE-0002Qs-00 for ; Sun, 14 Apr 2002 17:27:44 -0400 Original-Received: (qmail 10648 invoked by uid 1000); 14 Apr 2002 21:30:52 -0000 Original-To: Neil Jerram In-Reply-To: Original-Lines: 65 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:171 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:171 Neil Jerram writes: > If we can agree this, it would be good to do it in 1.6, No. :-) > Thien-Thi> alternatively, we need to document *why* 1.6 chooses > Thien-Thi> to rob the users so, at least to ourselves. "This > Thien-Thi> has been found to be too tricky, and is no longer > Thien-Thi> supported" is, although not dis-honest, still pretty > Thien-Thi> lame. > > Upon reflection, I agree. Yeah, ok. Let me try to explain. (This is the new workbook/modules/modules-and-shared-libs.text.) 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. 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). 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. 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. > More generally, looking back through mailing list history, it's > actually astonishing how much support for various stuff that Guile > has _lost_ along the way. I'd say we didn't lose it, we freed us from it. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user