[gccsdk] Shared library status update

alan buckley alan_baa at hotmail.com
Wed Jan 23 10:54:19 GMT 2008

> On Tue, 22 Jan 2008 20:42:16 Adam Richardson wrote:
> In message , alan buckley
> wrote:
>>> 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:
>> 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?)

One of the main points is that you get the most recent library version.

When you build a program you very rarely will be linking it to a specific
version, but you will be guaranteed that the public interface to it is 
identical for any version you use. This allows for bug fixes and
improvements to a shared library to be of immediate benefit for all
programs that use that library without you needing to upgrade all
the programs.

The contract for the shared library is that it should not break binary
compatibility. If it does you need to rename the library.

So my reasons are that a central location can give the latest version,
give consistant installation instructions, and stops different versions of
the same files being spread over the internet.

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

I quite agree with this, if you are providing something on a CD it should
have all the dependencies on it. To me a simple directory with the
required library files ready to drop on the installer alongside the
application would be enough.

I'm not proposing anything that would prevent this. I just think that
for internet distribution, getting the libraries from a central location
would be a good idea.

>>>> 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 was probably being unclear - 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. :(

I agree with your points here. But unless you go for a full installer that
installs everything then you are going to have to give the users
instructions on how to install the libraries. So it will add a new level
of complication however it is done.

Unfortunately, installing the first shared library will always be a pain
as the user will have to first install the shared library manager etc.
(Hopefully this could install the other components needed when
it is first run).

After that it should be fairly straight forward as they should just
need to drag the libraries to the Shared Library Manager to install

[snip technical bits about zip in a zip]
>> 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.

As this is talking mainly about the interface to the user it has to be subjective,
so what I'm talking about is what seems to me to be the simplest way to
present this. I don't think I'm saying there are any good technical reasons
against anything mentioned.

So in summary to try to make my position clear, in my opinion it would be
nice if:

1. There was a shared library manager control panel configuration program
that could show what's installed and allow merging by dropping a library
file on top of it.
2. This program used the existing packaging stuff from LibPkg.
3. Libraries should be distributed from a central location where possible.

This doesn't stop the program also allowing double-clicks on a new
file type to do the installation. Or the libraries being included in the
same location if necessary (mainly for CD ROM type distribution).

I'm not stuck up on these points though. The only thing I would argue
strongly for is that shared libaries and the supporting programs can
be distributed automatically by riscpkg as well as whatever scheme
is decided upon and the two can peacefully co-exist.


Share what Santa brought you

More information about the gcc mailing list