[gccsdk] Shared library status update

Adam lists at snowstone.org.uk
Tue Jan 22 12:42:16 PST 2008

In message <BAY101-W20A9D91BF325DA21A0AC50F03D0 at phx.gbl>, alan buckley

> > 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:
> >>>> [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 riscos.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.

For what reasons would it be better?

(Is it because that it ensures the most recent library version is used?
Perhaps I'm confused here, but I thought that if you build a program to
link with a specific library at runtime, only that version will ever be
used - otherwise, how can you be sure it's going to work, with all the
different potential libraries it might link with?)

I think it is important that an app could be provided on a CD and, in
any case, we shouldn't assume people have the time to be searching out
the dependencies for an application.

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

OK. My question was just that - I didn't understand what you were
suggesting - sorry!

> > 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
> components.
> Even the "application directory" philosophy of RISC OS still
> frequently needs modules that are outside of the directory.

Yes, and as has been pointed out, the current system for distributing
and updating modules isn't that great. We've got the opportunity to
avoid the same mistakes with shared libraries. :)

My concern is that we don't forget the users (and usability) of this
system. If it is too arduous, either for the developer or for his users,
then he'll just link the libraries statically, no matter how technically
sophisticated the library merge system is. :(

> > > > 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.
> [snip]
> I've still to be convinced that a user can't be told to just drag a
> library to the installer.

OK, but you've snipped whatever bit of the argument you're not convinced
about and I haven't seen you give the reasons for your opinion
elsewhere. (Sorry if I missed it somewhere.) If there are good technical
reasons against it, then it would be good to know what they are so we
can think sensibly about the extent we do (or don't) need to trade-off
one objective of the system for another.

Adam Richardson          Carpe Diem

More information about the gcc mailing list