[gccsdk] Shared library status update

alan buckley alan_baa at hotmail.com
Fri Jan 18 01:01:57 PST 2008

> On Thu, 17 Jan 2008 12:53:19 Theo Mrkettos.org.uk
> On Wed, Jan 16, 2008 at 08:35:39PM +0000, Adam wrote:
>> Hmm, OK, well, let me summarise the main discussion from then, as I saw
>> it. I am sure I will make some miss-quotes so apologies in advance, and
>> corrections are welcome!
> I've been avoiding wading in here as I'm not able to do any actual work on
> this, but a few little suggestions:
>> Martin argued that this is an imperfect system which is likely to result
>> in user-error. In particular he pointed out that it leads to confusion
>> about the difference between the "master" DSO-Libs and the "skeleton"
>> DSO-Libs.
>> As an alternative, he suggested that the "master" DSO-Libs should be an
>> active object which would handle the merging, invoked by the !Run file
>> of the distributed library.[1]
> That would seem sensible. There's a side question of whether the active
> object can upgrade its own upgrader. With my security hat on (and once
> we've got the 'RISC OS is full of holes so why bother' argument out the way)
> I'd suggest not, that the upgrader must be upgraded separately. If only
> because this stops it breaking itself and makes it easier to maintain.
>> Alan suggested a scheme based around libPkg which would be a super-set
>> of the scheme outlined by Martin.
> That would be a better solution, if someone is willing to do it. It would
> mean people could use RiscPkg to manage their self-installed libraries, even
> if they didn't want it to manage their applications.

I'm willing to at least make an attempt at creating the installer. I would want to
use C++, the Toolbox, a modified version of the Dreamscape library and
LibPkg (plus their dependencies). I would hope that others would be able to
at least help with the documentation and graphics and I would definately need
people willing to test it to destruction.

[snip new filetype and download problems]

> The structure of RiscPkg zips is already defined, so how about adding a
> little dummy application inside called !InstallMe? This then does:
> IfNotThere SharedLib:... Error Need SharedLib...
> Run SharedLib:!Merge .^

[snip details of how this could work]

Can't we just provide a control panel program like sysmerge that they just drop
the package file on to install?. This could also give options to see what is currently
installed and allow removal as well.

Mind you this doesn't actually rule out the other suggestions for launching it.

Personally, I'd hope that we could just make it clear what to do with the libraries
through documentation and not bother with allowing double-click installs or
having to put extra stuff in the packages.


Share what Santa brought you

More information about the gcc mailing list