Example installation: gcc

STORE really shines with a lot of small applications. These are really hopeless to keep track of with a usual installation, but easily installed and maintained with STORE. However, STORE can also manage more complicated programs, like gcc. This means the installer of the programs must be more experienced, but also that others can use a complex program without great pain in installing it.

As of the current version, gcc is quite easy to install on the 'supported' architectures: configure with the prefix you wish, in this case /store, and say 'make bootstrap ; make install'. This takes a lot of disk space but is otherwise mostly painless.

The problem with gcc in STORE stems from two facts:

  1. gcc itself has mechanisms for specifying target architectures and versions.
  2. gcc needs a tree of 'fixed' include files that is very different in content between platforms.
Both of these mean a lot of files will be specific for differing architectures, and would need to be marked as 'unneeded' for all other architectures.

Instead of marking all these files with their specific architectures, they are all put in an architecture-dependant directory. The current semantics of such a directory implies that these files are all optional, and that they all are implicitly tagged with the directory's tag. This simplifies the master version tree significantly, but means some extra pain in the installation process. The installation process may, however, be largely automated as long as everything works.

The binary files under the arch-dep directory need not have their own tags, but using postinst during installation, they usually will have their own tags.

The resulting layout of the version tree will then look like this:

ver-2.4.5 +-> bin 
          +-> man +-> man1 
          +-> doc +-> gcc 
          +-> emacs +-> info 
          +-> lib +-> gcc-lib@alpha +-> alpha-dec-osf +-> 2.4.5 
          |       +-> gcc-lib@dsosf1 +-> mips-dec-osf1 +-> 2.4.5 
          |       +-> gcc-lib@dsult4 +-> mips-dec-ultrix +-> 2.4.5 
          |       +-> gcc-lib@m88k +-> m88k-dolphin-svr3 +-> 2.4.5 
          |       +-> gcc-lib@sgi3i4 +-> mips-sgi-irix4 +-> 2.4.5 
          |       +-> gcc-lib@sun4os4 +-> sparc-sun-sunos41 +-> 2.4.5 
          |       \-> gcc-lib@sun4os5 +-> gcc-lib +-> sparc-sun-solaris2 
          |                           \-> sparc-sun-solaris2 +-> 2.4.5 
          |                              
          +-> alpha-dec-osf@alpha +-> include 
          +-> m88k-dolphin-svr3@m88k +-> include 
          +-> mips-dec-osf1@dsosf1 +-> include 
          +-> mips-dec-ultrix@dsult4 +-> include 
          +-> mips-sgi-irix4@sgi3i4 +-> include 
          +-> sparc-sun-solaris2@sun4os5 +-> include 
          \-> sparc-sun-sunos41@sun4os4 +-> include 

(Actually, there lots of extra directories and include files under the 2.4.5 directories, but that's not relevant to this discussion).

The compilation sequence would look like this, showing '$' only as the prompt:

$ mkdir /store/store/khym/gcc
$ cd !$
$ ftp prep.ai.mit.edu
[... get gcc-2.4.5.tar.gz...]
$ zcat gcc-2.4.5.tar.gz | tar xvf -
$ rm gcc-2.4.5.tar.gz
$ mv gcc-2.4.5 src-2.4.5
$ shadow -a gcc -m khym -s khym -A sun4os4
$ cd src-2.4.5-sun4os4
$ ./configure --prefix=/store sparc-sun-sunos41
$ make bootstrap
$ make install
$ cd ../ver-2.4.5
$ postinst -a gcc -s khym -A sun4os4 -v 2.4.5
$ postinst -t 300 -p /store/lib/gcc-lib
$ rm bin/sparc-sun-sunos41-gcc@sun4os4
$ mv lib/gcc-lib lib/gcc-lib@sun4os4
$ strip lib/gcc-lib@sun4os4/sparc-sun-sunos41/$version/cc1*
$ strip lib/gcc-lib@sun4os4/sparc-sun-sunos41/$version/cpp*
$ mv sparc-sun-sunos41 sparc-sun-sunos41@sun4os4

The extra run of postinst is necessary because gcc possibly installs include files with old modification times. This procedure has been evolved through time, and will need changes as new versions of gcc becomes available. The overall concepts remain, however, the same as for simple applications.

Up : Installing software in STORE, Previous: Example installation: ange-ftp.

Index

arnej@lise.unit.no