[gccsdk] Shared Library Distribution

Adam lists at snowstone.org.uk
Wed Nov 21 14:05:19 PST 2007


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?

Clearly a RiskPkg solution is the best one :) but I suspect there's a
large population of users who have an instictive aversion to RiskPkg and
won't want to use it.

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?


> > By the way, could I plead the application is called something other than
> > !DSO-libs?  That's quite an obscure name from the user perspective.

Yes, I agree, though I guess it's not a huge issue.

> >  How about something like:
> > 
> > !SharedLib
> > !DLL  (at least uses terminology people might already be familiar with)
This isn't familiar, to me at least.

> > !SharedObj
> > !DynLibs
> > !DynLoaded
> > !Libraries
> > etc
> 
> I don't mind.  I believe Lee went for that application name. Lee ? Shall
> we change that ?
> 
> > I'm trying to keep under the 10 character limit to avoid pain. 
> > There have been some problems where people tried to unpack GCC on a
> > 10 char filing system.  As shared libraries are likely to hit a much
> > wider class of users than GCC, it might be worth considering some
> > kind of detection of truncation.

I'm not convinced of the need to stay under 10 characters - it's a
pretty old restriction. If doing so imposes no penalties though then I
guess it might be worthwhile.

However...


> > If you have a short directory name you can at least find !SharedLib
> > and then report if internal names are truncated rather than an
> > unintuitive 'can't find !SharedLibraries' message which doesn't
> > explain the truncation problem to the user[1].  Perhaps have an
> > !SharedLib.AQuiteLongTestName and something checks if it's truncated
> > and refuses to work if so.

I don't think it's worth spending developer time on molly-coddling those
still using such old filing systems ;)


> > [1] The typical problem case here is someone unpacks the files on
> > machine A with 10 char filenames and copies them across to machine B
> > with long filenames.  Machine A will find them (because of the FS
> > truncation support) but machine B won't.
> 
> Unpacking !GCC on a 10 char limited FS resulted in a corrupted result even
> for eg GCCSDK 3.4 and I can't remember hearing surprises on that.
> 
> But your point is relevant for !DSO-libs or whatever it's going to be
> renamed to as those will be used by a different audience.  Isn't this a
> potentional general problem which better get addressed by RiscPkg ?

As far as I know RickPkg is committed to requiring large directories and
long filenames.

Adam

-- 
Adam Richardson          Carpe Diem
http://www.snowstone.org.uk/riscos/




More information about the gcc mailing list