[gccsdk] Autobuilder packaging site and ELF

John Tytgat John.Tytgat at aaug.net
Sat Feb 2 09:57:10 PST 2008


In message <BAY101-W24D644A62954159C8214A9F0300 at phx.gbl>
          alan buckley <alan_baa at hotmail.com> 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.

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

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

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

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

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.

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.

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

Maybe we should now decide if we want to go for both static and shared
building capabilities in Autobuilder or fully switch to shared library
building ? Personally I would not like to see the static building dropped
unless it is clear what implications shared library based programs have
in practise and we're happy with it.

> I will add command line options to add-riscpkg so that this behaviour
> can be overridden easily.
> 
> I will initially look at the packages I have already managed to build
> on GCC3.4.6 to update them. The SDL games should be a good test
> of the system as they all share the sdl library and many use things
> like SDL_Mixer and SDL_Image that have dependencies themselves
> on other libraries.
> 
> 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 would be particularly helpful if the developers most closely
> assosiated with shared libraries and the autobuilder, i.e. John Tygat,
> Lee Noar and Peter Naulls, could let me know if it is okay by them
> to proceed as outlined above.

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 ?

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

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven




More information about the gcc mailing list