[gccsdk] Shared library status update

alan buckley alan_baa at hotmail.com
Wed Jan 9 01:26:05 PST 2008

> On Tue, 8 Jan 2008 14:03:21 -0800 Peter wrote:
> Lee wrote:
>> I originally intended to sub divide !DSO-Libs.lib to categorise the
>> libraries that were installed (hence the system directory), but I'm not
>> sure that's really necessary, so perhaps a flat structure should be used.
>> The easiest way to package would seem to be within a skeleton !DSO-Libs
>> including their runtime and compile time symlinks (rather than
>> generating them automatically during installation as Linux does). If we
>> could standardise the way library names include their version number,
>> then that could be used for version control and riscpkg would know
>> whether to overwrite an existing version or not. We don't have to
>> enforce this, but if a library doesn't include its own version in the
>> filename, then it runs the risk of overwriting a newer version.
> Yes, we want to use standard names, and I see no reason not to use
> precisely RISC OSified versions of the names that the build
> systems split out - i.e, stand Unix naming, but we don't want to
> rely on filenames for versioning.
> The point of packaging is for the package manager to know precisely
> the files which belong in a package. It's true that most shared
> libraries will be versioned in their filenames, we we can't
> tell from that what libraries belong together, or about other misc
> resource files that are used by the library. The package manager
> maintains all this information in its database.

If we decided to use the riscpkg format for the shared library
packages it contains the version in the control file and so the
filename versions are unimportant for distribution. Though
it would be sensible to be consistant.

The version control would all be done by the package manager
which will remove older versions when installing the new version
regardless of filenames.

> In any case, I'll begin my own experiments, but on the presumption
> that there will be further fixes in the pipeline.

If we are going with the riscpkg format and putting things in
to !DSO-libs, then it should be fairly easy to modifiy the
ab_package script for a library to generate the run time library
as well as the development library. Please have a look at the
Packaging.html file I checked in and/or contact me if it isn't obvious
what I had in mind.

My thought was that for a library the runtime package would
just contain the library and its links in a !DSO-libs directory, which
depends on other packages that installs the Elf loader and the
base !DSO-libs directory.

The main thing I'm not sure about is how to support systems with
less than 77 files per directory and no long filename support.


Get Hotmail on your mobile, text MSN to 63463!

More information about the gcc mailing list