What should be in SharedUnixLibrary

Nick Burrett nick at dsvr.net
Mon Dec 24 04:33:35 PST 2001

Christian Ludlam <chris at recoil.org> writes:

> On 22 Dec Nicholas Clark wrote:
> > The above problem is the general RISC OS problem that you can't have more
> > than one version of a module (of given name) loaded at once, isn't it? [In
> > that they really weren't intended to implement shared library linking. And
> > shared library systems on Unix let multiple versions (given different major
> > numbers) be loaded at once. Which is what you need, as you bump the major
> > version number up when you make incompatible changes, such as structure
> > layouts]
> > 
> > Sorry, not a solution.
> > 
> > Also, the Toolbox problem was compounded by the toolbox modules being put
> > into ROM before they were mature. As then an early loading program would
> > RMEnsure somemodule 0.3 (say) and be quite happy with the one in ROM. But a
> > later program would need 0.5, and be unable to load, despite 0.6 being in
> > !System. Hence the appearance of UnplugTbox in !Boot to bodge round the
> > mess.
> You can get round this to an extent by setting bit 31 of the module's
> finalisation entry point. This means the module remains in memory after it's
> been killed, so anything requiring a later version of the module can load it
> without worrying about apps already linked with the earlier version.

Assuming we have a backwards and forwards compatible API though.


More information about the gcc mailing list