Michel Schinz <Michel.Schinz@epfl.ch> writes:
> Martin Gasbichler <email@example.com> writes:
>> I think this shows that it's indeed worthwhile to talk about dynamic
>> libraries in the packaging standard.
> Interesting. From your example, I gather the following:
> - For packages which link to dynamic libraries, some code *has* to be
> executed before the package can be used (at least a call to
> dynamic-load). That is, simply loading some file in the config
> package is not sufficient.
That's how I did it, but as I read your email, another possibility
came to my mind: it would be possible to put this code in the normal
source file as a top-level expression. This code would then load the
dynamic library when the package is loaded. Using a record resumer we
could even ensure that the dynamic library gets loaded if the package
was dumped in an image (see the REINITIALIZER record in
I would still prefer having an exec script but wanted to mention this
option as well.
> Thus, if we still want to make it easy for script authors to use a
> package, it seems that scsh needs to be extended like you suggested
> in a previous message, i.e. with a way to lookup (in SCSH_LIB_DIRS)
> and load files in *any* package. (I like your proposal, by the way).
> - We might also want to specify a standard location for shared
> objects. I think using a sub-directory called "lib" as you did in
> your example is fine. It will create a slight conflict with sunet,
> which currently has some Scheme code in "lib" but that can certainly
> be changed.
The scheme code could go to a sub-directory "scheme".
> Another point to keep in mind is that these shared objects (.so
> files) are platform-dependent. So if we want to make it possible to
> install shared objects for several platforms in a single directory
> (e.g. on a server), we need to put the name of the platform
> somewhere. We could imagine something like one sub-directory per
> platform, i.e. lib/<platform>. The name of the platform should be
> taken from autoconf, I guess.
Yes, that's definitely a must for network file systems. Fortunately,
we don't have to take care of LD_LIBRARY_PATH as we load the dynamic
libraries ourselves and can stick to your "a package is a directory"
> Are there other things to think about?
We probably should fix the name of the initialization function to
s48_PACKAGENAME_init or so.
> As a side note, I worked these days on a small library to install
> packages, and wrote (scsh) install scripts for pgscsh, sunet and
> sunterlib. I'll post another message here today or tomorrow about
Great, I'm looking forward to it!
> I'm sorry that it takes me so long, but I have little spare time
> these days.
Well, this is not what I would consider "long" in the usual scsh terms