Last update: May 13, 2008
The GNOME SlackBuild (GSB) Build System Wiki
This page describes how to build the binary GSB distribution from the actual GSB source code. It is recommended that you read through (end even print) this entire document before starting the build process.
For other aspects of the GNOME SlackBuild Build system, please return to Main page.
Checking Out the GSB Build System from Subversion
The first step to building your GNOME Desktop with GSB is to check out our source code from our svn repository. Please make sure to do so in a directory on a disk partition that has quite a bit of free space. The GSB Build System itself doesn’t not take up much disk space, however, the source tarballs are downloaded directory into the build tree. A full source build tree can take up to 1GB of disk space. We currently maintain several SVN branches to produce our GSB releases.
You can check out the GSB Build System using the following command:
Current Branch
This tree contains the latest and most up to date GSB sources. As such, at any time it may be broken (ie, will not build fully) or may cause your system to explode in a shower of wires and capacitors if you run it. This tree is usually only for the latest Slackware/Slamd64 current and may not work on other releases.
$ svn co http://svn.gnomeslackbuild.org/gsb/trunk gsb
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/trunk
GNOME 2.22 Stable Tree
This is our GNOME 2.22 stable tree for Slackware 12.1 and Slamd64 current (which will soon become Slamd64 12.1) ONLY. This tree is kept up to date with the GNOME 2.22 sources and will be maintained (at least for the short->medium timeframe) with the minor 2.22.x releases GNOME provide.
$ svn co http://svn.gnomeslackbuild.org/gsb/branches/gsb-2.22 gsb22-stable
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/branches/gsb-2.22
GNOME 2.20 Stable Tree
This is our GNOME 2.20 stable tree for Slackware and Slamd64 12.0 ONLY. This tree is kept up to date with the GNOME 2.20 sources and will be maintained (at least for the short->medium timeframe) with the minor 2.20.x releases GNOME provide.
$ svn co http://svn.gnomeslackbuild.org/gsb/branches/gsb-2.20 gsb20-stable
Or browse in svn: http://svn.gnomeslackbuild.org/viewvc/branches/gsb-2.20
This may take a long time depending on the speed of your internet connection. The svn GSB tree does not only contain our own scripts and patches for building the GNOME Desktop, but also contains external links to other software available via svn, such as the x264 Codec library and NetworkManager. These external links via svn will ease the building of such packages. However, the majority of the tree will consist of SlackBuild build scripts (.SlackBuild), Slackware package description files (slack-desc), and Slackware package requirements (slack-required) files.
If you have difficulties building a package, before reporting any errors, please make sure your Build Tree is up-to-date. Changes to the trunk can happen daily, and the fix may already be applied to the build tree. To update your tree to the latest version, change into the gsb directory and run:
$ svn update
Downloading the Source Code
Apart of the GSB Build System is a download script written in perl, which is kept up to date with all the versions and download locations of all the source tarballs used by the GSB Build System. This is for the convenience of any user who wishes to build GSB from scratch. The download script is designed to download the source tarballs for the entire GSB Build Tree, which can be up to 1GB. Users may find they either do not want this, and may only want to use the GSB Build Tree for building a few select packages. In this case it may be easier to download the tarballs by hand into each package’s directory.
The perl download script is called gsb_update.pl, and it is found in the gsb/bin directory. There are two settings you may wish to change before running the download script. To do this, you will need to edit the GSB.pm file found in the directory gsb/lib/perl/GSB.
################################################################################ # Config Options # 'mirror' => 'ftp://ftp.gnome.org/pub/gnome' my $wget_options = "--continue --cache=on --passive-ftp --progress=bar:force --timeout=30 --tries=3";
- ‘mirror’ – You can change the mirror you download from to a location nearer you. You can find a list of GNOME Mirrors at http://www.gnome.org/~mjs/MIRRORS.html
- wget_options – The
gsb_update.plscript uses wget to download all the soure tarballs. If you would like to change the default settings for the GSB download script, please consult the wget manual.
When you are ready to run the download script, change into the gsb/lib directory and run:
$ ../bin/gsb_update.pl --dl --edit --build=gsb
--dl
This argument will tell gsb_update.pl to download all the source tarballs.
--edit
This argument will tell gsb_update.pl to edit the SlackBuild to reflect the version number which is downloaded from the GSB.pm source files, as well as reset the build number if the version has changed.
--build=gsb
This argument will tell
gsb_update.pl to tag all the packages with “gsb”. When the package is built, the string “gsb” will be appended to the package build number, i.e., 1gsb.tgz, rather than 1.tgz. This will help differentiate it from regular Slackware provided packages.
Downloading the sources may take a while depending on the speed of your internet connection. Don’t be surprised if it takes a few hours. :)
Disk Space
Disk space requirements are the first priority. It may seem surprising at first, but a complete GSB Build may require up to 8GB of disk space! There is a lot of software that will be compiled during the build process and it is important to ensure that enough free disk space is available before starting the build scripts. The disk space usage is broken down as such:
GNOME SlackBuild Source Tree: ~261MB
This includes all the GNOME SlackBuild scripts, as well as all external svn sources.
GNOME SlackBuild Source Tarballs: ~1GB
This is approximate for a full source download. If you only wish to build a few single packages then if may be easier for you to download each source tarball individually.
Temporary building space: ~6GB
Some larger applications like Mozilla Firefox, Mono, and Boost C++ require enormous amounts of space to build. Despite the fact that the resulting binaries are often only about 30MB, while building they may need up to 3-6GB for object files and libraries.
Installed Software: ~2GB.
As the GSB Build system steadily progresses building packages, it will need to install them on the build system for the sake of satisfying dependencies. In other words, the system on which GSB is built will also have it installed. A full installation of GSB will required approximately 2GB
GNOME SlackBuild Packages: ~563MB
GNOME SlackBuild will produce standard tgz format Slackware packages, placing all the built packages into the default directory /tmp/gsb-packages. A full GSB Build will require space for about 360 individual packages.
Development and Build Tools
A full development system is also required to build GSB. You will need to ensure that the following standard Slackware packages are installed on your system:
autoconf, automake, bin86, binutils, doxygen, flex, gcc, gcc-g++, gettext-tools, guile, indent, kernel-headers, libtools, m4, make, perl, pkg-config, python, subversion
All of these packages are installed on a “full” Slackware install, but some users who installed a custom selection may not have these packages installed. They are available on any Slackware CD, or available from any Slackware mirror. For those users who are interested, we provide a set of tagfiles to be used during a Slackware installation which will install the same set of Slackware packages we use on our own build system. They are available in the trunk/lib/gsb/tagfiles/build-box directory.
Build System Cleanup and Requirements for GNOME 2.22
One caveat for builders is that some standard Slackware packages will need to be upgraded, most notably glib2 and libwnck. Others will need to be upgraded for added functionality, but these packages are optional. Please take a look at all the packages that may require replacing in our Replaced Packages file.
# The following is a list of packages that can replace official Slackware packages. # # Packages listed under 'Required' are Slackware packages that must be replaced # by corresponding GNOME SlackBuild versions in order to use GNOME 2.22.1 on Slackware 12. # Reasons for their replacement are given within brackets. # # Packages listed under 'Optional' are packages which replace official Slackware # packages, but their replacement are only necessary for added functionality, or # certain GNOME applications. Their replacement is recommended, but not required # if you do not plan to use certain applications, or are dead set against replacing # any Slackware provided packages. # # List last updated: May 4th (stevek) # ********************************************** Slackware 12.1 is required to run GNOME 2.22.1 ********************************************** -- Required Package Replacements for GNOME 2.22.1 on Slackware 12.1 -- glib2: ( > 2.15 required by libgnome 2.22, Gvfs 0.2.3, and Nautilus 2.22) libwnck: ( > 2.22 required by Metacity 2.22, and GNOME 2.22 at large) -- Optional Replacements -- mozilla-firefox: (Provides shared libraries. Required by: Epiphany, Yelp, GNOME Python, DevHelp) compiz-fusion: (Slackware comes with compiz 0.7.4, compiz-fusion is cooler though and offers GNOME support) libgsf: (Slackware's libgsf lacks GNOME support; required for GNOME Office applications like Gnumeric)
You will also need a live internet connection in order to build some packages.
It is also recommended that you have the latest patches for Slackware applied.
Build Settings
When building GSB, there are several environment variables which can be used to tweak and customise the build process. GSB supports two methods of setting these environment variables, described below.
The first option is to use the bash builtin “export” to manually set the option and export it to all sub-processes. This can be done with a command like:
$ export VAR="VAL"
This can be repeated for as many environment options as you want to set. You must remember to set these options every time you begin a build process as they will not be saved accross multiple builds.
The second option is to create a gsb.options file in the src/ directory. The gsb.options file is read at the begining of every build process, and the options specified in this file will be saved accross multiple builds. Using the gsb.options file is especially useful for repeat builds or for developers who want to set specific options when testing.
The gsb.options file should contain exactly the same “export” commands which would be used manually on the command line (see above). The advantage of putting them into the gsb.options file is that the options will always be read, no matter whether you remember to manually export them on the command line.
Here are the common environment variables which can be set to effect, tweak or customise the build process:
ARCH
Setting the ARCH allows you to over-ride the default base architecture type for GSB. You can use this environment option to build GSB for, say, x86_64 or the powerpc architecture type. The architecture type set when building GSB determines the absolute minimum processor type required to run the produced binaries. In other words, if you set ARCH=i686 the resulting code will NOT work on an i586 or earlier CPU. These ARCH types are currently recognised by the GSB SlackBuild scripts: i386, i486, i586, i686, x86_64, powerpc.
The default is “i586”.
TUNE
This option is very similar to the ARCH environment option except that the resulting binaries are scheduler-tuned to the given processor type. This means that the binaries will be tuned to run with better performance on the CPU type specified with TUNE, but will still work without problems on CPU types going back to the value specified for ARCH. TUNE can be set to any valid CPU type within the architecture type specified with ARCH. For example, if ARCH=i586, TUNE could be set to i686. For an ARCH type of x86_64, TUNE must be set to one of the 64 bit processor types, currently: k8, opteron, athlon64, athlon-fx.
The default is “i586”, except for an ARCH type of x86_64 where it is “k8”.
You may find more information on ARCH and TUNE settings in the gcc man pages.
DISTRO
Setting DISTRO to anything other than “slackware” allows GSB to be built on different (Slackware based) distributions. For example, this can be set to “slamd64” when building GSB on the 64 bit Slackware based distro Slamd64.
The default is “slackware”, and should not be over-ridden unless you are specifically building for another distribution.
TMP
During the package builds, temporary data will need to be stored on disk. This option specifies the directory where that temporary data can be written. Make sure the default (or any directory you specify) has enough free space for the build process, plus the completed packages and logs.
The default is /tmp.
PKGDEST
Once a package has been built it will be stored in the directory specified with this option. The default for this option is affected by the value of the TMP environment option detailed above (referred to as $TMP below).
The default is $TMP/gsb-packages.
LOGSDIR
As the GSB build process proceeds, a log of the output from each package build is logged for later debugging. This environment option specifies the directory where these log files will be stored. This option is not used by individual package SlackBuilds but is used by the top-level SlackBuilds which control the build processes. The default for this option is affected by the value of the TMP environment option detailed above (referred to as $TMP below).
The default is $TMP/gsb-buildlogs.
Advanced Build Settings
The following options are less common but allow highly specific customisation of the build process. You should not set these options unless you know exactly what needs to be set for each. GSB comes with fairly optimised complier settings, but if you really want to squeeze every last cycle out of your CPU, you can adjust compiler and make settings. Be wary though! Sometimes hyper-optimising can break software that depends on careful or ISO-standard math routines, for example, liboil.
GSB_CONFIGURE_FLAGS
Any options specified in this environment variable are ADDED to the package specific options passed to the ./configure command in the SlackBuilds. If this option is set globally (ie, set with export or in gsb.options) it sets the additional options passed to ./configure for EVERY SlackBuild in GSB. Therefore, make sure that any setting given in this environment option is valid for EVERY ./configure used in GSB.
By default, when ARCH=x86_64, ./configure is automatically passed—libdir=/usr/lib64.
GSB_TUNE_FLAGS
This environment option allows you to set the specific tuning options gcc should use when compiling/linking the binaries in packages. There are many, many gcc options which can be set to optimise/tune the binaries – see the gcc man page for full details. Setting this option over-rides the default tuning options specified in the SlackBuild files – these options are NOT added to the default ones. Make sure you add any of the default options from the SlackBuilds back to this environment option if you choose to use it. Tuning is specific to each ARCH, with the defaults being:
- i386, i486
-O3 -march=$ARCH -mtune=$TUNE
- i586, i686
-O3 -march=$ARCH -mtune=$TUNE -pipe -fomit-frame-pointer -ffast-math
- x86_64, with default TUNE
-O3 -march=k8 -mtune=k8 -pipe -fomit-frame-pointer -ffast-math -fPIC
- x86_64, with custom TUNE
-O3 -march=$TUNE -mtune=$TUNE -pipe -fomit-frame-pointer -ffast-math -fPIC
- powerpc
-O2 -march=$ARCH
Building Packages by Section – SlackBuild Arguments
GNOME SlackBuild is organized by logical sections, like “libraries” or “platform”, under which are placed related packages. Each section is governed by a section build script, which will build all the package within its section in the proper build order. These section build scripts have their own unique arguments as follows:
--help
Show this help screen.
--list
List the packages which will be built in this section.
--force
A package will not be built if a package of the same name is already installed, or any of the pre-requisite packages are not installed. This option over-rides the checks and attempts a build (which will probably fail) anyway.
--no-skip
During the build process, packages that are up to date (ie, the package version and build numbers match the
corresponding SlackBuild) will not be rebuilt. This option forces packages to be rebuilt regardless of the version and build numbers. This does not affect the pre-build checks for installed packages (see—force).
--no-metafiles
Do not create the .txt and .md5 files for each package which would usually be produced during a build. Normally, metapackages are created for use with slapt-get and the binary install method. If you do not need to create these metapackages (normally, only for binary distribution managers), then you may specify this argument.
--no-prune
Normally, when a package is built and copied to the destination directory, any previous package(s) of the same name are deleted – it is assumed the new package is to replace any which were built previously. This option prevents previous packages being deleted from the destination directory, possibly leaving more than one package of the same name (but with different version or build numbers) laying around.
--no-patchesdir
When rebuilding packages which already exist in the main package directory, the default is to put the new packages in the patches directory. Using this option completely disables the use of a patches directory.
--no-cleanup
By default, any source, temporary build and package directories will be deleted once the package is built. This option prevents those files from being removed.
--no-install
Build packages but don’t install them. This should only be used for testing individual SlackBuilds as it can cause some package builds to fail, specifically those which may rely on another package being auto installed first.
NOTE: Options are passed down to the individual package SlackBuilds where appropriate.
Building Individual Package – SlackBuild Arguments
Each individual SlackBuild script has its own arguments. By default, it will not run if the package it builds has previously been installed. It will also check for basic build requirements, and display package names of any missing required packages. Each SlackBuild will configure, build, and create a Slackware .tgz package complete with a slack-required and slac-desc file.
--force
The package will not be built if a package of the same name is already installed, or any of the packages required to build are missing. This option over-rides these checks and attempts a build anyway. It cannot be used with the -update switch.
--update
This switch will make the build script test each package version as defined in the SlackBuild script against the currently installed package. If there is a difference, the script will remove, rebuild, and reinstall the package. It cannot be used with the -force switch.
--no-cleanup
By default any temporary source, build and package directories will be deleted once the package is built. This option prevents those files from being removed.
--no-install
Build the packages but don’t install them. This should only be used for testing individual SlackBuilds. It may cause the section build to fail when required packages are not installed and the dependency checks fail.
--help
Show this help screen.
Building GNOME SlackBuild
Building every package provided by GNOME SlackBuild will take a long time. We have separated packages into sections in order to aid building in a proper order, as well as to make maintaining dependencies easier. If you do not wish to run the entire build in one go, you may build section by section (ie, by hand), following the build order below. We have, however, provided there is one overarching script, gsb.SlackBuild which will run each of the section SlackBuild’s in the proper order.
- tools
- libraries
- platform
- desktop
- bindings
- applications
- accessibility
- administration
- office
- mono
- extras
- themes
- compiz
- networking
- ooo
- meta
- testing
This master list is defined within the gsb.SlackBuild file itself, and each section SlackBuild has it’s own defined build order. The binary distribution provided compiles every package listed, but if you prefer to roll your own GSB packages, then feel free to edit the order to suit your own needs or wants. But be warned, if everything breaks, it’s not our fault! :)
Also, be aware that before running the build script, you must be root in order to build GSB.
$ ./gsb.SlackBuild
When Things Go Wrong
Don’t panic. :) We’ve worked hard to ensure that all the packages within the GSB Build Tree will build on Slackware. If you have difficulties building a package, before reporting any errors, please make sure your Build Tree is up-to-date. Changes to the trunk can happen daily, (and even hourly!), and the fix may already be applied to the build tree. Before reporting errors, please make sure to have updated your tree to the latest version. Change into the gsb directory and run:
$ svn update
If you discover yourself still having difficulty building a certain package or packages, let us know and we’ll try our best to resolve any issues. There are several mailing lists used by the GNOME SlackBuild project. These are hosted by Google Groups, and in order to read or post to the mailing lists and groups, you must first subscribe. Give IRC a try first, but if no-one is around, then please do send an email detailing the problem you are having, with all the appropriate details, like OS and compiler versions, the exact error, and steps to reproduce it. You may also want to check the archives or FAQ to see if the problem is already known.
Try one of the following (in this order):
- Check the FAQs and other helpfull resources on the website:
http://gnomeslackbuild.org/support/
- For bug reports and feature requests, please check our issue tracker for previous reports of the same problem and possible solutions. If your bug or feature is not solved or listed, add it:
http://dev.gnomeslackbuild.org/
- Join the GSB User Discussion Mailing List:
http://gnomeslackbuild.org/lists/
Firstly, check the archive to see if anyone else has had a similar problem which has already been solved. You will not get any points for requesting help with a problem that has already been addressed.
The mailing list is the easiest and preferred method of contact for support type issues – it allows us to keep an archive of questions and answers. Note: You must be subscribed to the mailing list in order to post messages.
- Join the #gsb IRC channel on irc.freenode.net and ask questions – without whinging, bitching, repeatidly asking the same question, repeatedly asking ‘Is anyone here?’ or being a general idiot. We are a friendly bunch (well, mostly anyway) and willing to help if you act civilly. :) On IRC, we may appear to be always online, but we are frequently away from the console and you may not receive an answer for a while. But stick around since we’ll try to give a reply, eventually :)
You may also use this wiki. For reporting any new issues, or feature requests, please see our Issues page. You may create new issues or features using the drop-down menu on the right.