[gccsdk] Shared Library Distribution

Martin Wuerthner martin at mw-software.com
Thu Nov 22 00:26:53 PST 2007


In message <23746c454f.admin at snowstone.org.uk>
          Adam <lists at snowstone.org.uk> wrote:

> In message <9b685d454f.Jo at hobbes.bass-software.com>, John Tytgat wrote:

>> In message <20071121113207.GE18542 at chiark.greenend.org.uk>
>>           Theo Markettos <theo at markettos.org.uk> wrote:
>> 
>>> On Wed, Nov 21, 2007 at 09:35:21AM +0000, alan buckley wrote:
>>>> 
>>>> Looking at the layout of this, I assume you can just ship the a
>>>> zip file with !DSO-libs.lib.libMyLib/so and the symlinks which can
>>>> be dropped directly on top of your existing !DSO-libs. Is this
>>>> correct?
>>> 
>>> There's presumably a need for some kind of merge tool like !SysMerge
>>> - you don't want to replace new ones with old ones.
>> 
>> Yes that's correct.  It's very similar to !System.

> But sysmerge is built into the OS and DSOMerge won't be, so is it
> inevitable that users are going to end up having to jump through a few
> hoops to get GCC4-based apps working?

No. I suggest shipping the merge tool as part of !DSO-libs (or 
whatever it will be called eventually), then it is guaranteed to be 
there. Upgrades to the merge tool can be handled using the same 
mechanism as upgrades to the standard library files.

Furthermore, the unfortunate convention of !System updates being 
shipped in a directory called !System seems to have created the idea 
that !DSO-libs updates should be shipped in a directory called 
!DSO-libs. Can we please avoid that at all cost? Of all names in the 
world, the name of the central directory is exactly the one that 
should not be used, precisely because we specifically do not want 
users to simply drop the update over their existing directory (or 
worse, replace their existing directory with the skeleton update). I 
suggest that a single, different directory name is used for updates. 
So, if the main directory is called !SharedLib, then the upgrades 
would be shipped in !SharedUpd. The central directory would define the 
icon for the upgrade directory so that updates do not need their own 
sprites file (and to further encourage developers to use the official 
update directory name). The icon should look very similar to the 
central directory icon but with a big plus on it to make it clear that 
it is an update. The !Run file of the update could check for the 
presence of the central directory and run the merge tool stored in it.

The above mechanism makes it much easier to update the shared libs 
directory than updating !System because the only thing users need to 
do is to double-click on the update. At the same time, it actually 
offers more reliability than the current !System mechanism because 
users cannot accidentally drop the update over the central directory.

> Perhaps a scheme could be defined where applications can be distributed
> containing their dependencies and the DSOMerge tool, which would be
> invoked somehow when the app is first run?

I do not think it would be a good idea to ship the merge tool with 
each application. It would be far better to ship the merge tool with 
the lib directory. One shared libs directory and one merge tool.

Martin
-- 
---------------------------------------------------------------------
Martin Wuerthner          MW Software          martin at mw-software.com
---------------------------------------------------------------------




More information about the gcc mailing list