[gccsdk] Shared library status update

alan buckley alan_baa at hotmail.com
Mon Jan 21 06:33:16 PST 2008

> On Fri, 18 Jan 2008 18:16:09 Adam wrote:
> In message , 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:

>>>> 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 just mentioned them to see if there was any objection to them.

>> 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!

Well there should be a minimal need for graphics anyway;-)

>>>> [1] 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.

I know it's a bit of a pain. But in my opinion it would be much better if we
could just point people to where to get libraries from rather than have to
include them with every app that needs them.


>> 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?

I can't see this would prevent being able to double click.

> 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.

I assume you just double click on !Boot the same was as you do
to get a SysMerge and then select it from the Configurations.


> 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.

Unless you move to a packaging system I don't see how you can avoid
some complication if your application is made up of several separate

Even the "application directory" philosophy of RISC OS still frequently
needs modules that are outside of the directory.

>>> 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.

I believe LibPkg does currently rely on the package being in a zip file. To do
this you would probably need to put a zip file in the zip file. It's not doing
anything odd with the zip format itself, but I believe it's does things like
using the zip file catalogue.


I've still to be convinced that a user can't be told to just drag a library
to the installer.


Telly addicts unite!

More information about the gcc mailing list