Re: Getting off the ground (also matrix stuff)

[Vollmer Marius <mvo@zagadka.ping.de>]

I haven't yet tried Chrisens package, so I don't have any specific
> details, but maybe I can shed some light on the general picture.

Telford Tendys <telford@eng.uts.edu.au> writes:

> [...] and I know there's some scheme command that must be executed
> to make the module link itself dynamically -- but I couldn't get it
> to work <aaargh>.

When everything is setup correctly, using (use-modules ...) should be
all that is needed to bring in dynamically linked objects.

> Can I switch off dynamic modules completely and just have the whole
> lot statically linked to mguile?

Yes, you can.  Just link the libraries to mguile and call their
`module initialization functions'.  These functions all have names like

    scm_init_<module-name>_module

So you should probably just grep thru the sources and call functions
that match the pattern.  When you do this, you still need to call
(use-modules ...), tho.  Just the dynamic linking step will be
omitted.

> Another question bugs me. When running on Linux systems, dynamic
> linking is usually done with `shared object' libraries (*.so.* files)
> so why is the guile dynamic linking done differently?

You can use *.so files just fine with the low-level dynamic linking
functions.  In fact, the low level functions are just a thin wrapper
around the functions provided by the OS.  On Linux (and all other ELF
systems I suppose) this is dlopen/dlsym and they can of course access
*.so files.  On win32, I expect dynamic-link to work with DLLs just
fine (when someone writes the OS specific code for this).

Now, the procedure that makes on demand linking of shared libraries
happen that provide compiled code modules uses the low-level interface
to dynamic linking.  In addition to that, the code also searches for
*.la files that are essentially information files about shared
libraries.  These *.la files are installed by libtool.  I think it's a
winning concept.

If I may predict the future: libtool will mature to do everything
anyone ever wants from a shared library system, in a portable way.  To
achieve this, we will get a new, unified shared library format, the
*.la files.  These files are only a wrapper around the real OS
specific shared libraries and contain enough information about such a
library, so that the GNU dld package can do its things.  The dld
package will provide uniform dynamic linking across a wide range of
platforms.

So we will build shared libraries with libtool and dynamically link
them with dld.  On all platforms, in a uniform way.

[...]
> Is this totally unrealistic?

This is how it has always been.
 
> Since I got a message about documentation being under review and got
> no documentation at all with the 1.2 release of guile, you must
> understand that I'm going mostly on comments in the source code here.

I have recently posted some lines about dynamic linking to this list,
under a subject of "Documentation Repairs" (which was not at all
clever, I admit).

> ...still rambling with more questions...
> 
> One more issue, when both guile and mguile start there is about a 2
> second delay on my system. Is this supposed to be there?

It is a well known problem that Guile has a slow startup.  Let me
recommend guile-unexec from the Guile contrib archive

    ftp://ftp.red-bean.com/pub/guile/contrib/misc/guile-unexec.tar.gz

It might need a bit of overhaul and kludging to make it work with
mguile, but it is a dramatic speed improvement (factor 30 is not
exaggerated, I think).

hth,
 Marius