[gccsdk] Shared library status update
lists at snowstone.org.uk
Fri Jan 18 10:16:09 PST 2008
In message <BAY101-W25B0A0EB6D5911472D80BF0420 at phx.gbl>, alan buckley wrote:
> On Thu, 17 Jan 2008 12:53:19 Theo Mrkettos.org.uk
> > On Wed, Jan 16, 2008 at 08:35:39PM +0000, Adam wrote:
> > > 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.
> > 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.
Yes, seems sensible.
> > > 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).
All of those things are outside my experience ;)
> 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.
I'd be happy to help on the first and last of those three, but graphics
is definitely not my forte!
> > >  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,
That's how I assumed it would work. In particular I've been thinking
from the angle of how to distribute your own software, which has
dependencies (rather than how to distribute the libraries by themselves
from risco.info or wherever). In this context, I'd expect the library
file to be in the archive next to the application directory.
> > but if it's a RiscPkg archive it's already zipped - does SparkFS
> > cope with zipfiles within zipfiles?
I've no idea, having never used SparkFS but some quick tests here using
InfoZip don't reveal any problems with this.
(Of course, having the file in a zip archive doesn't rule out getting the
relevant mapping in users' mimemap files in the future.)
> > 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.
Well, this scenario is basically depending on users having the central
library repository already installed. I'm not sure if there's a neat way
of getting round that. (I don't actually think this is too big a problem
as you would hope SharedLib would quickly become as ubiquitous as the
SharedUnixLibrary module - and it only has to be installed once, unlike
the libraries themselves.)
> > 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>.^
> Can't we just provide a control panel program like sysmerge that they
> just drop the package file on to install?.
Do you mean as opposed to being able to double-click the library
file/application/zip? If so, how would it be invoked? Assuming SharedLib
would live in !Boot.Resources, I wouldn't like to see users having to
open up their boot sequence and load SharedLib that way.
> 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.
I think "double-click installs" are a valuable goal. Installing some
applications on RISC OS has become too complicated as the dependencies
issue has grown (as shown by regular questions on the newsgroups) and
shared libraries have the potential to exacerbate the problem.
I would love to use shared libraries for my applications, but don't want
to burden users with complicated installation instructions. I'd like my
apps to work "out of the box" (or even "in the box" ;) ). This is, after
all, one of the key benefits of the "application directory" philosophy
on RISC OS which still sets it apart from other OSes.
> > 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.
Well, this is OK, but I do like the idea of minimizing the number of
objects you're faced with when you open up (as a user) your downloaded
archive. In this case, in particular, there is a danger that people will
extract the contents to a "temp" directory. This is a recipe for carnage
since all the different downloads would have the same directory names in
the root of the archive, so you could end up with exactly the situation
(merge-by-directory-structure) we're trying to avoid!
Adam Richardson Carpe Diem
More information about the gcc