[gccsdk] Autobuilder packaging site and ELF

alan buckley alan_baa at hotmail.com
Mon Feb 4 06:42:27 PST 2008

> On Sat, 2 Feb 2008 18:57:10 +0100 John Tytgat wrote:
> In message 
> alan buckley  wrote:
>> Now I've got GCC4 running on Cygwin I want to look into
>> how to start generating ELF packages for the autobuilder
>> website.
>> So ELF programs can be installed smoothly by riscpkg
>> I would like to create packages of what is currently !DSO-libs.
>> These packages could then be made dependencies of any
>> ELF program to ensure they will just run without any
>> manual intervention from the users.
> Ok.
>> What I would like to do is create the following packages.
>> ELFLoader
>> This will be a new application directory !ELFLoader. Here the
>> SOMManger will live. The boot file will set variables so the
>> SOMManager can be found, file types for symlinks and ELF
>> executables and the run type for ELF executables
> BTW, it is SOManager.

Yes it is, and I can't see why I stuck an extra M in here either:-)

>> SharedLib
>> A new application directory !SharedLib. This will be the
>> skeleton application for storing shared libraries. The boot
>> file will set up the GCCSOLib path.
>> C-libs
>> The base c shared libaries. This will just be the libraries
>> and symlinks to be installed into !SharedLib.lib
> It is not clear cut to me what you mean with C-libs. Is that libgcc_s
> included ? libm ?

I was basically thinking of all the libraries that weren't C++. Is there
other stuff that isn't C related in the currently shipped DSO-libs?

>> C++libs
>> The stdc++ shared library. Installed into !SharedLib.lib
> I start wondering if we really need to do a split of C/C++ whatever base
> shared library and not provide one package holding the SharedLib application
> and all shared gcc/C/C++ libraries. And I guess each GCCSDK 4 release
> could imply an update of this package.

I think for simplicity you are correct here. I originally preferred the idea
of keeping the container app separate as it would rarely be updated,
but am willing to try bundling them altogether to start with and testing
to see if that causes any problems.

>> These will all be installed into Boot.Resources.
>> Can anyone tell me where etc.ld/so/cache from the current
>> !DSO-libs should go?
> I believe Lee can better answer this but I thought this was a cache file
> under control of the ld shared library.

Lee has answered this.

>> Initially I intend to create these packages by hand. But once
>> tested, thay can be built when the GCCSDK is built.
> Currently this is all done in gcc4/riscos/build-it, I don't see why a
> new structure can't be done there immediately. Basically during the
> native RISC OS build (i.e. give "riscos" as parameter to build-it) all
> files to be released gets built and placed in gcc4/release-area/full and
> is ready to be tested over network. There is a packaging switch for
> gcc4/riscos/build-it "-pkg" which copies the bits gcc4/release-area/full
> into zip files. That's how pre-release 1 zip files were made.

I'll look into this some more.

> So I would suggest:
> 1) Currently we have a fully !DSO-libs in gcc4/release-area/full. This
> could be split into !ELFLoader and !SharedLib. The former containing
> the SOManager ELF loader and only dependency for static ELF binaries.
> The latter holding all shared libraries we currently have in GCCSDK and
> this will be an additional dependency for the shared library ELF
> binaries.
> [ SharedCLibrary and RISC OS modules don't have any dependency of
> course. ]
> 2) With -pkg switch we create zip files and riscpkg files. Or are we going
> to drop zip deliverables ?
> If you could do the packaging of !GCC, that would be great.
> It might be a good idea to break out the -pkg code from riscos/build-it to
> a separate script doing only the packaging.

This looks sensible. I'll have a look at the scripts.

> Aside, currently we have a subdir !DSO-libs.lib.system and we (Lee and I)
> are no longer convinced of its added value. So better have the links and
> shared libraries all in !SharedLib.lib directory like found after a
> successful cross-compile build and this can much better automated as well.
>> With the packages in place, autobuilt shared libraries will
>> just need to add a dependency to the SharedLib package and
>> applications will add a dependency to C-libs or C++libs.
>> The dependency chain will mean that, for instance, a
>> dependency on C++ libs will cause C-libs, SharedLib and
>> ELFLoader to all be loaded if not present.
> I would make it simplier, only have ELFLoader and base-SharedLib package
> where the latter contains all the shared libraries we have in gccsdk build.

OK, as I said above I'll look at this as my initial approach and report if I
find any problems.

>> To integrate this into the autobuilder I will remove the automatic
>> call to elf2aif and modify add-riscpkg so by default it will add
>> a dependency to C-libs.
> Removing elf2aif does not mean that you automatically will need the
> shared libraries but only need the ELF loader. You need to make sure
> that all code is build in shared library mode (i.e. drop the -static
> compile and link option).

Thanks for the warning.

>> Before I can start on anything though I need to know if there are
>> any objections.
> No objections in general, but see comment above. ;-)

It looks like I'm safe to start at least trying to get my machine to build
a few packages, without it all being a wasted effort;-)

> Just a question as I'm not sure if we have a consensus on the following:
> how will shared libraries outside the GCCSDK build be distributed by this
> plan ?

I don't think we have a concensus.  It didn't appear to me from the
other discussions that there were any objections to creating packages
in the riscpkg format, so I thought I could go ahead with this part of
the distribution plan while people are still mulling it over.

>> As we have no way of simplifying installation without using riscpkg
>> presently, I will add notes to the manual installation page on the
>> autobuilder website to tell users what to do so set up the elf system
>> by hand by copying the various components out of the relevant
>> package zip files.
> I'm a bit afraid by this idea : wouldn't it be better to have a suitable
> named file in the root of each zip file explaining what to do for those
> wanting to do a manual install ? Something like a
> "How To Install This Manually" named file ?

I don't know what would be best here. As there isn't a plan for
people who don't want to use riscpkg I just thought a few
instructions on the web site to get these people running for now
was the best that could be done.


Free games, great prizes - get gaming at Gamesbox. 

More information about the gcc mailing list