Re: [gccsdk] Dynamic linking

In message <55F08281.5090506@sky.com>
Lee Noar <leenoar@sky.com> wrote:

>Yes. We have a dynamic linker and libdl just as most (all?) Unix type
>platforms do. But these work on a per program basis; they have no
>knowledge of other programs. That's where SOManager comes in. It
>controls the loading of shared libraries and keeps track of which
>programs are using them so that there's only ever one instance of
>a library in memory no matter how many programs are linked to it.
>When the dynamic linker needs a library to satisfy a program's
>dependency, it asks SOManager to load the library if it's not already
>present and then give it a new copy of its R/W segment.

I suspect that my requirements are not so demanding. Most use of Lua
is on platforms where dynamic linking is commonplace; so it makes
sense for Lua (which is just a C library) to be highly modular, to
have a core of the most commonly used libraries (implementing io,
strings, tables, coroutines, ...) with a periphery of more specialized
libraries to be linked in dynamically. But RISC OS is different, and
until now was not able to avail itself of such an arrangement.

>I'm not clear on if you've had to put a lot of work into supporting
>plugins previously or whether your using a solution that comes from the
>Lua source.

The latter. "loadlib" is a C library. The programmer in Lua sees it mostly
through the function "require", and the "package" library. The function
"require", when called, first looks to see if the table "package.loaded" contains
its argument as a key. If it does then the module referred to by the
argument has already been loaded. If it does not then it tries to find a
loader function for it, searching "package.path" (in the case of Lua
modules) or "package.cpath" (in the case of C modules). There is a
complicated minuet of fallbacks; in case of failure the
value "nil" is returned, otherwise the loader function becomes a
new value of "package.loaded", indexed by the module's name, and is
called to load the module. The loader, in the case of C modules, will
be implemented essentially by "dlopen".

>If the original source has support for dlopen, then this should work
>with some minor changes to plugin pathnames.

I hope to find out.

>I assume though that there is a C/C++ based runtime interpreter

C based (ANSI as much as possible).

>that handles the dynamic loading of libraries?

Yes, that is the "loadlib" part. Lua is designed as a bunch of libraries,
as orthogonally as possible, so that users can pick and choose what
ingredients are to go in the stew when they compile it.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK