What should be in SharedUnixLibrary

Nicholas Clark nick at ccl4.org
Fri Dec 21 16:12:28 PST 2001


On Thu, Dec 20, 2001 at 10:44:16AM +0000, Theo Markettos wrote:
> Regarding the implementation, I think avoiding the Toolbox mess is vital.  If
> app A uses the toolbox, it loads the relevant modules.  Then app B comes
> along, and needs a newer version of the modules.  They are there on disc
> (maybe have just been installed, or there are multiple copies on disc), but
> because app A is already using the toolbox it can't load newer modules. 
> Also, even killing all the apps using a module doesn't help because other
> modules (Window, Iconbar etc) depend on the Toolbox module.  I'm not sure how
> to implement that (knowing not too much about UnixLib internals), but some
> way towards it would be useful.
> 
> If the above was solved, one idea might be to embed the module in an

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.

Nicholas Clark



More information about the gcc mailing list