Offline Software Installation Details

From Daya Bay

Jump to: navigation, search

Installation is simple and described here. If things go wrong, this topic collects some details for solutions.


Prerequisites

Script tools

dybinst needs:

bash 
Bourne again shell. It may work on a plain Bourne shell.
wget or curl
command line download tool.
build tools 
svn, make, compilers, etc (but not CMT, it will provide this).

nosebit requirements

To install the testing system (nosebit external) you will need an svn version that supports svn --ignore-externals checkout this means at least 1.2 (circa 2005)


Assumed libraries

Many basic libraries are assumed to exist and typically do on a "usual" platform or can be trivially installed via native package management tools. They are considered outside the scope of dybinst.

As they are numerous, this list is not exhaustive:

libc/libm 
needed by everything
libbz2-dev 
needed by Boost
X11, OpenGL (MesaGL), MySQL 
needed by ROOT
libXp-devel, xorg-x11-xbitmaps 
needed by OpenMotif
uuid-dev 
needed by Gaudi
libreadline-dev 
optional, but useful for Python

Note: it is common for systems to only have the run time versions of these libraries and be missing the compile time versions. Make sure you have the "-dev" (Debian and related) or "-devel" (RH and related) versions of the package.

Figure out which libraries used

Use ldd -v command to the .so files under InstallArea of each project, one can find a list of dependencies. The following script will give you a list of shared libs required:

find /path/to/NuWa-trunk -name *.so -exec ldd -v {} \; | grep so | sed -e '/^[^\t]/ d' | sed -e 's/\t//' | sed -e 's/.*=..//' | sed -e 's/ (0.*)//' | sort | uniq

Here is a list of shared libs required by dybgaudi for 64 bit SL5.4 system:

/lib64/ld-linux-x86-64.so.2
/lib64/libcom_err.so.2
/lib64/libcrypto.so.6
/lib64/libcrypt.so.1
/lib64/libc.so.6
/lib64/libdl.so.2
/lib64/libexpat.so.0
/lib64/libgcc_s.so.1
/lib64/libkeyutils.so.1
/lib64/libm.so.6
/lib64/libnsl.so.1
/lib64/libpthread.so.0
/lib64/libresolv.so.2
/lib64/librt.so.1
/lib64/libselinux.so.1
/lib64/libsepol.so.1
/lib64/libssl.so.6
/lib64/libutil.so.1
/usr/lib64/libbz2.so.1
/usr/lib64/libcurl.so.3
/usr/lib64/libdrm.so.2
/usr/lib64/libfontconfig.so.1
/usr/lib64/libfreetype.so.6
/usr/lib64/libGL.so.1
/usr/lib64/libGLU.so.1
/usr/lib64/libgssapi_krb5.so.2
/usr/lib64/libICE.so.6
/usr/lib64/libidn.so.11
/usr/lib64/libjpeg.so.62
/usr/lib64/libk5crypto.so.3
/usr/lib64/libkrb5.so.3
/usr/lib64/libkrb5support.so.0
/usr/lib64/libncurses.so.5
/usr/lib64/libpng12.so.0
/usr/lib64/libreadline.so.5
/usr/lib64/libSM.so.6
/usr/lib64/libstdc++.so.6
/usr/lib64/libX11.so.6
/usr/lib64/libXau.so.6
/usr/lib64/libXdmcp.so.6
/usr/lib64/libXext.so.6
/usr/lib64/libXft.so.2
/usr/lib64/libXi.so.6
/usr/lib64/libXmu.so.6
/usr/lib64/libXpm.so.4
/usr/lib64/libXp.so.6
/usr/lib64/libXrender.so.1
/usr/lib64/libXt.so.6
/usr/lib64/libXxf86vm.so.1
/usr/lib64/libz.so.1

MySQL Server

Dybinst installs the MySQL client by default, but not the server.

If you are a local site librarian or want to run the code as a stand-alone project, you will probably want to install a local MySQL server.

The instructions for installing and configuring the server are at: MySQL_Installation.

Required disk space

A full build will need close to 3GB of disk space available. Make sure you invoke dybinst from a directory that has this much available.

[CL]: a recent build (0.2.0) required about 10GB. After building, you can trim this considerably by removing all the .o files.

[djaffe]: a build of trunk 23oct09 produced 9.8GB. Removing external/build and external/tarFiles reduced the size to 5.3GB

Required time

Depending on your CPU, network and disk speed you can expect the install to take a minimum of 2-3 hours. This is the time obtained on a dual Opteron using local RAID0 striped disks and downloading from BNL's network.


Progress

As it runs, dybinst will print terse status messages. To see details run the following in a second window:

tail -f dybinst_date_time.log

where date and time the date and time when you start.

Partial running

By default, dybinst starts from an empty directory and (eventually) gives you a fully built set of packages. It is also possible to do this step wise by replacing the "all" argument with the step you wish to take:

./dybinst <STEP>

To see what steps are available run

./dybinst help


Options

Projects step rebuilding options

The default dybinst run skips rebuilding if the projects directories exist, such as

 $SITEROOT/gaudi/GaudiRelease/$CMTCONFIG

This behaviour can be modified by the rebuild options "-r" and "-c" .

Rebuild options :

  • -r : dumb rebuilding by removing release/output directories of projects,
  • -c : attempt at clever rebuilding based on comparisons of the svn last changed revision of project folders, eg $SITEROOT/dybgaudi, between dybinst project builds

For example, a dumb rebuild of all projects (no checkout or externals ):

./dybinst -r trunk projects

An update followed by a rebuild of only changed projects :

./dybinst trunk checkout 
./dybinst -c trunk projects

Environment

The dybinst script is intended to do its job with out you needing to have any special environment.

It is not recommended but it can run in a shell that has already been set up for a NuWa. It will warn you that a CMTCONFIG variable is already defined and then wait for an interactive acknowledgement. To pass this prompt in a noninteractive invocation one can do the following:

echo y | dybinst [...]

Modifying Internals

To handle unusual situations it is possible to control its internals by putting shell commands in

~/.dybinstrc

or in the directory from where dybinst is invoked:

.dybinstrc

In general you must understand the dybinst script to know what to put in these files. However, some possibilities include:

Overriding default compilers

GCC 4.1 (such as used on modern Debian) fails to compile some parts of Gaudi. If you can install older versions you can get dybinst to use them by doing something like the following:

  1. make a local bin/ directory
  2. symlink the desired compiler versions into this, eg: ln -s /usr/bin/g++-3.4 bin/g++
  3. add this bin/ location to the PATH variable in a .dybinstrc file
  4. do the same for gcc

[CL]: this sometimes doesn't work - genreflex will often disregard your PATH, so it won't pick up the correct g++ version. You may have to go and symlink your system's main g++ version (usually in /usr/bin, do a "which g++") to the correct version. If you do this, don't forget to change gcc, cc and c++ to match.

Overriding external/ install method

Note: this feature currently does not work.

The script relies on others to populare the external/ area. Some try to guess among a subset of build methods. If you would like to force a method you can set DYBINST_EXTERNAL_METHOD. Not all scripts respect all methods. Some methods are:

debian 
look in standard Debian locations for Debian'ized versions of the package, then make symlinks into external/
environ 
check for standard environment variables used to point to elements of the package and symlink these into external/
source 
download, build and install from source

Package installation scripts that respect these:

  • geant4.sh (all methods)

FTP/HTTP Proxy

If you are behind a firewall that requires you to use FTP/HTTP proxies you will need to set some environment variables. For example, for the BNL wireless network you need:

export http_proxy=http://192.168.1.140:3128/
export ftp_proxy=$http_proxy

And on the BNL internal network, you need:

export http_proxy=http://192.168.1.130:3128/
export ftp_proxy=$http_proxy


For configuring SVN for a proxy see this topic.

Trouble Shooting

If dybinst fails to do its job check the file

dybinst-YYMMDD-HHMMSS.log

for any clues. Some common problems are listed in the Offline Software Installation Trouble Shootting topic.

dybinst tries to be idempotent. As a consequence, once it succeeds in any particular step, that step doesn't need to be redone. So, if trouble does arise, only bother debugging the step that failed.

Projects problems

  • It may fail to build if you do not have the binary "lockfile" under "/bin/sh".
    • Debian: install "procmail" package.


Package-specific problems that people have encountered are listed below. If you find new ones, please add their solution.

Root problems

  • Root 5.18.00 failed to build on the UIUC NPL server with errors like this:
:/site/local/ups/prd/cern/Linux/2006/src/packlib/zebra/mqg/mzgar1.F:168:undefined reference to `_gfortran_line'"

It was probably due to compiler problems. The problem was solved by running "unsetup root" and install again.

OpenMotif problems

  • OpenMotif may fail to build "wmluitok" with an error about missing symbol "main". If so, make sure "libfl" is installed. This is part of the "flex" package.

Aug 2008, Cheng-Ju Lin: if you run into the above problem on PDSF, one solution is to modify the openmotif.sh file in the installation script directory. You'll need to change " ./configure --prefix=$OpenMotif_home " line to " ./configure --prefix=$OpenMotif_home CFLAGS="-L/usr/local/pkg/flex-2.5.33" "


  • If you got error like this:
 I18List.c:23:28: X11/bitmaps/gray: No such file or directory
 I18List.c: In function `CreateGCs':
 I18List.c:2074: error: `gray_bits' undeclared (first use in this function)
 I18List.c:2074: error: (Each undeclared identifier is reported only once
 I18List.c:2074: error: for each function it appears in.)
 I18List.c:2075: error: `gray_width' undeclared (first use in this function)
 I18List.c:2075: error: `gray_height' undeclared (first use in this function)

You need the xbitmaps package.

Boost problems

  • If boost build fails with an error about "libbz2" make sure this library is installed. It provides "bzip2" compression.
    • Debian: install "libbz2-dev" package.

OpenScientist problems

  • Coin needs OpenGL development libraries and will may fail to find GL/glu.h if they are not installed.
    • Debian: install the "libglu1-mesa-dev" package
  • The build may fail due to missing "-lXi" missing library
    • Debian: install the "libxi-dev" package

Geant4 problems

  • Geant4 may fail to build if Xaw development files are not installed.
    • Debian: install the "libxaw7-dev" (or higher) package.
  • Geant4 may fail when there is another version of geant4 installed and G4INCLUDE is defined.
    • Fix it with "unset G4INCLUDE", then restart the installation.

nosebit (testing system) problems

If your dybinst run fails while building the nosebit external, examine the log for messages such as :

 === pkg_xinstall : checkout url http://dayabay.phys.ntu.edu.tw/repos/tracdev/bitten/trunk/bitten into name bitten in workdir /home/wangly/NuWa/dybinst/external/nosebit
 svn --ignore-externals co http://dayabay.phys.ntu.edu.tw/repos/tracdev/bitten/trunk/bitten bitten
 svn: invalid option: --ignore-externals
 Type 'svn help' for usage.

This means that you have a very old svn (<1.2) that does not support "--ignore-externals" . As only the testing system requires this functionality (and nosebit is kept as the last external) you can install NuWa without nosebit by doing :

 ./dybinst trunk all      ## fails at nosebit external with svn < 1.2
 ./dybinst trunk projects ## proceed with projects

Mac OSX installation

29 Nov 07, David Jaffe: I used 'dybinst trunk all' to install on my Mac OSX 10.4 using the BNL wireless network. It worked fabulously, here are several comments:

  1. http and ftp proxies must be set since dybinst uses svn (http) and wget (ftp) to install software
  2. The installation of 'boost' reports a failure, but this can be ignored and one merely needs to invoke 'dybinst trunk all' again as the needed boost libraries are actually successfully built.

(I've tried to fix this and I can't see the problem. I note that the Fink installation actually patches Boost very heavily on installation; I might try replicating this proceedure at some point, but I'm worried about possible problems as a result. I'm reluctant to simply remove the check, since it might be indicating a real problem. ---Nathaniel)

  1. Although dybinst is supposed to be idempotent, mysql will get installed each time you invoke dybinst. Nathaniel fixed this with revision r2109.
  2. The total time for installation was ~4 hours.


Problem compiling external package ROOT (Tiger 10.4.?)

4 Dec 07, Dan Dwyer: dybinst failed while compiling root with the error: Failed to find Xlib.h. The X11 headers in my version of OS X were in a non-obvious directory (/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include). The following commands create symbolic links to these headers, allowing the installation to complete successfully.

sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/DPS /usr/include/DPS
sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/GL /usr/include/GL
sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/X11 /usr/include/X11
sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/expat.h /usr/include/expat.h
sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/fontconfig /usr/include/fontconfig
sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/freetype2 /usr/include/freetype2
sudo ln -s /Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/ft2build.h /usr/include/ft2build.h


Problem compiling external package ROOT (fresh Leopard 10.5.1 CD install --> 10.5.4 via software update)

July 08, Cheng-Ju Lin: Need slightly different symbolic links for Leopard...

sudo ln -s /Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/GL /usr/include/GL
sudo ln -s /Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/fontconfig /usr/include/fontconfig
sudo ln -s /Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/freetype2 /usr/include/freetype2
sudo ln -s /Developer/SDKs/MacOSX10.5.sdk/usr/X11/include/ft2build.h /usr/include/ft2build.h

For some 10.5.5 users, may need to replace directory path above from "MacOSX10.5.sdk" to "MacOSX10.5u.sdk"


10 Jan 08, Wei Wang: If dybinst suffers an error while generating map for libGiGa while installing on Mac, it is very possible you're using pre-existing packages instead of doing a clean and complete installation. The easy solution is to clean up your environmental variables related to the 3rd party packages, i.e. pretending that you have none of the 3rd party packages needed by NuWa, then you can install NuWa successfully. This is the easy solution without bothering what env's are interfering the installation. The environmentals I disabled (most of them are from FINK on my MacBook so I simply disabled the "source /sw/init.sh" in my .bashrc):

1. GEANT4 related ones; 2. ROOT related ones; 3. CMTROOT etc.


26 Feb 08: Problem with case-insensitive OS X solved by Simon Blyth

10 Mar 08: Simon Blyth's advice on diagnosing build problems

26 Nov 08: Offline Software Installation on Mac OS X 10.5.5

Scientific Linux Installation

For more details see

Ubuntu installation

For more details see:

Fedora installation

For more details see:

64 bit Linux

  • if your build fails with an undefined symbol for the vtable of G4VBasicShell when building GiGa, and you're using gcc 3.4, try upgrading to gcc 4.1
  • As of 30 Jul, the dybinst script can successfully install NuWa on 64-bit version of
  1. Scientific Linux 5.0 & 5.3
  2. Fedora Core 5
  3. Ubuntu 7.10
  4. Ubuntu 9.04
Personal tools