[gccsdk] Shared library status update
theo at markettos.org.uk
Thu Jan 17 04:53:19 PST 2008
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"
> 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.
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.
>  This has shades of the old Impression document-directory approach to
> me. How about the distributed libraries just being a single file
> (perhaps a zip file with a different filetype) which, when
> double-clicked, would invoke the merge tool?
That might be a bit annoying for download purposes, because servers know to
send .zip as a binary file but not for .rolib (or whatever). Even if they
did come as binary you'd have to tweak your MIMEMap to associate that
extension with the filetype. You could put the .rolib file in a zip for
protection, but if it's a RiscPkg archive it's already zipped - does SparkFS
cope with zipfiles within zipfiles? I think you might want something to
cope with the base case if no libraries at all were installed, rather than
'file type &123 not known' which you'd get if you double clicked the new
filetype on a clean machine. We could do a self-extracting archive, but
then it gets a bit messy embedding executable code (eg old SEAs broke on the
26-32bit transition, and they're a security problem).
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 <Obey$Dir>.^
LibPkg would have to learn how to install from already-decompressed package
files, if it doesn't already. It'd have to cope with the archive being
decompressed on the fly by SparkFS rather than by itself, but if it's not
doing anything odd with the Zip format that should be OK.
You can then ship libsomething.zip which can be installed automatically by
RiscPkg or manually by opening the zip and clicking on !InstallMe. Same
sort of principle that people are used to inserting CDs into Windows
machines and either autorun or clicking on setup.exe. They usually
ignore all the other files on the CD when doing so - here they'd learn to
ignore the other files intended for RiscPkg. In Debian-speak RiscPkg
corresponds to 'apt-get install libsomething' and !InstallMe corresponds to
'dpkg --install libsomething.deb' - using the underlying library in a
If you were modifying RiscPkg you might be able to arrange the archive
layout more neatly, but I don't know if that's an option. I think I'd
suggest avoiding a special case for libraries if we can.
More information about the gcc