- General information
- Data readiness
- Grid and Cloud
- Infrastructure
- Online Computing
- Software Infrastructure
- Batch system, resource management system
- CVS->Git
- Computing Environment
- Facility Access
- FileCatalog
- HPSS services
- Home directories and other areas backups
- Hypernews
- Installing the STAR software stack
- Provision CVMFS and mount BNL/STAR repo
- RCF Contributions
- Security
- Software and Libraries
- Storage
- Tools
- Tutorials
- Video Conferencing
- Web Access
- Machine Learning
- Offline Software
- Production
- S&C internal group meetings
- Test tree
Additional software components
Updated on Fri, 2016-08-12 12:08 by testadmin. Originally created by jeromel on 2007-12-27 16:25.
Under:
Scope & audience
Described in Setting up your computing environment, OPTSTAR is the environment variable pointing to an area which will supplement the operating system installation of libraries and program. This area is fundamental to the STAR software installation as it will contain needed libraries, approved software component version, shared files, configuration and so on.
The following path should contain all software components as sources for you to install a fresh copy on your cluster:
/afs/rhic.bnl.gov/star/common
Note that this path should allow anyuser to read so there is no need for an AFS token. The note below are sparse and ONLY indicate special instructions you need to follow if any. In the absence of special instructions, the "standard" instructions are to be followed. None of the explanations below are aimed to target a regular user but aimed to target system administrator or software infrastructure personnel.
System wide RPMs
Some RPMs from your OS distribution may be found at BNL under the directory /afs/rhic.bnl.gov/rcfsl/X.Y/*/ where X.Y is the major and minor version for your Scientific Linux version respectively. You should have a look and install. If you do not have AFS, you should log to the RCF and transfer whatever is appropriate.
In other words, we may have re-packaged some packages and/or created additional ones for compatibility purposes. An example of this for SL5.3 is flex32libs-2.5.4a-41.fc6.i386.rpm located in /afs/rhic.bnl.gov/rcfsl/5.3/rcf-custom/ which supports the 32 bits compatbility package for flex on a kernel with dual 32/64 bits support.
STAR Specific
The directory tree /afs/rhic.bnl.gov/star/common contains packages installed on our farm in addition of the default distribution software packages coming with the operating system. At BNL, all packages referred here are installed in the AFS tree
/opt/star -> /afs/rhic.bnl.gov/@sys/opt/star/
Be aware of the intent explained in Setting up your computing environment as per the difference between $XOPTSTAR and OPTSTAR.
OPTSTAR will either
- at BNL or to a remote site: be used to indicate and access the local software BUT may be supported through a soft-link to the same AFS area as showed above whereas @sys will expand to the operating system of interest (see Setting up your computing environment as well for a support matrix)
- at a remote site, will point to a LOCAL (that is, non-networked) installation of the software components. This space could be anywhere on your local cluster but obviously, will have to be shared and visible from all nodes in your cluster.
XOPTSTAR
The emergence of $XOPTSTAR started from 2003 to provide better support for software installation to remote institutions. Many packages add path information to their configuration (like the infamous .la files) and previously installed in $OPTSTAR, remote sites had problems loading libraries for a path reason. Hence, and unless specified otherwise below, $XOPTSTAR will be used preferably at BNL for installation the software so remote access to the AFS repository and copy will be made maximally transparent.
In 2005, we added an additional tree level reflecting the possibility of multiple compilers and possible mismatch between fs sysname setups and operating system versions. Hence, you may see path like OPTSTAR=/opt/star/sl44_gcc346 but this structure is a detail and if the additional layer does not exist for your site, later login will nonetheless succeed. This additional level is defined by the STAR login environment $STAR_HOST_SYS. In the next section, we explained how to set this up from a "blank" site (i.e. a site without the STAR environment and software installed).
On remote sites where you decide to install the software components locally, you should use $OPTSTAR in the configure or make statements.
Basic starting point
From a blank node on remote site, be sure to have $OPTSTAR defined. You can do this by hand for example like this
% setenv OPTSTAR /usr/local
or
% mkdir -p /opt/star % setenv OPTSTAR /opt/star
are two possibilities. The second, being the default location of the software layer, will be automatically recognized by the STAR group login scripts. From this point, a few pre-requisites are
- you have to have a system with "a" compiler - we support gcc but also icc on Linux
- you should have the STAR group login scripts at hand (it could be from AFS). The STAR login scripts will NOT redefine $OPTSTAR if already defined.
Execute the STAR login. This will define $STAR_HOST_SYS appropriately. Then
% cd $OPTSTAR % mkdir $STAR_HOST_SYS % stardev
the definition of $OPTSTAR will change to the version dependent structure, adding $STAR_HOST_SYS to the path definition (the simple presence of the layer made the login script redefine it).
Changing platform or compiler
32 bits versus 64 bits
If you want to support native 64 bits on 64 bits, do not forget to pass/force -m64 -fPIC to the compiler and -m64 to the linker. If however you want to build a cross platform (64 bit/32 bit kernels compatible) executables and libraries, you will on the contrary need to force -m32 (use -fPIC). Even if you build the packages from a 32 bit kernel node, be aware that many applications and package save a setup including compilation flags (which will have to be using -m32 if you want a cross platform package). There are many places below were I do not specify this.
Often, using CFLAGS="-m32 -fPIC" CXXFLAGS="-m32 -fPIC" LDFLAGS="-m32" would do the trick for a force to 32 bits mode (similarly for -m64). You need to use such option for libraries and packages even if you assemble on a 32 bits kernel node as otherwise, the package may build extension later not compatible as cross-platform support.
Other GCC versions
As for the 32 bits versus 64 bits, often adding something like CC=`which gcc` and CXX=`which g++` to either the configure or make command would do the trick. If not, you will need to modify the Makefile accordingly. You may also define the environment variable CC for consistency.
Summary
If ylu do have a 64 bits kernel and intend to compile both 32 bits and 64 bits, you should define the envrionment variable as shown below. The variables will make configure (and some Makefile) pick the proper flags and make your life much easier - follow the specific instructions for the packages noted in those instructions for specific tricks. Note as well that even if you do have a 32 bits kernel only, you are encouraged to use the -m32 compilation option (this will make further integration with dual 32/64 bits support smoother as some of the packages configurations include compiler path and options).
32 bits
% setenv CFLAGS "-m32 -fPIC"
% setenv CXXFLAGS "-m32 -fPIC"
% setenv FFLAGS "-m32 -fPIC"
% setenv FCFLAGS "-m32 -fPIC"
% setenv LDFLAGS "-m32"
% setenv CC `which gcc` # only if you use a different compiler than the system default
% setenv CXX `which g++` # only if you use a different compiler than the system default
and/or pass to Makefile and/or configure the arguments CFLAGS="-m32 -fPIC" CXXFLAGS="-m32 -fPIC" LDFLAGS="-m32" CC=`which gcc` CXX=`which g++` (will not hurt to use it in addition of the environment variables)
64 bits
% setenv CFLAGS "-m64 -fPIC" % setenv CXXFLAGS "-m64 -fPIC" % setenv FFLAGS "-m64 -fPIC" % setenv FCFLAGS "-m64 -fPIC" % setenv LDFLAGS "-m64" % setenv CC `which gcc` # only if you use a different compiler than the system default % setenv CXX `which g++` # only if you use a different compiler than the system default
and/or pass to Makefile and/or configure the arguments CFLAGS="-m64 -fPIC" CXXFLAGS="-m64 -fPIC" LDFLAGS="-m64" CC=`which gcc` CXX=`which g++` (will not hurt to use it in addition of the environment variables)
Software repository directory - starting a build
In the instructions below, greyed instructions are historical instructions and/or package version which no longer reflects the current official STAR supported platform. However, if you try to install the STAR software under older OS, refer carefully to the instructions and package versions.
perl
The STAR envrionment and login scripts heavily rely on perl for string manipulation, compilation management and a bunch of utility scripts. Assembling it from the start is essential. You may rely on your system-wide installed perl version BUT if so, note that the minimum version indicated below IS required.
In our software repository path, you will find a perl/ sub-directory containing all packages and modules.
The package and minimal version are below perl-5.6.1.tar.gz -- Moved to 5.8.0 starting from RH8
perl-5.8.0.tar.gz -- Solaris and True64 upgraded 2003
perl-5.8.4.tar.gz -- 2004, Scientific Linux perl-5.8.9.tar.gz -- SL5+ perl-5.10.1.tar.gz -- SL6+
When building perl
- Use all default arguments BUT when you are asked for compilation / linker args, add -m32 or -m64 depending on the platform support you are building. Those questions are (example for the 32 bits version):
- Any additional cc flags? [] -fPIC -m32
- Any additional ld flags (NOT including libraries)? [] -m32
- Any special flags to pass to cc -c to compile shared library modules? [] -fPIC -m32
- Any special flags to pass to cc to create a dynamically loaded library? [-shared -O2] -shared -O2 -m32
- If you build a 32 bits support on a 64 bit node, you may also answer "no" below but the defalt naswer SHOULD appear as no if you properly passed -m32 as indicated above.
Try to use maximal 64-bit support, if available? [y] n <--- you probably did ot pass -m32
Try to use maximal 64-bit support, if available? [n] <--- just press return, all is fine
- when asked for the default prefix for the installation, give the value of $OPTSTAR as answer (or a base path starting with the value of $OPTSTAR wherever appropriate). Questions include
- Installation prefix to use? (~name ok) [/usr/local]
- If the build warn you at first that the directory does not exists but proceed - to questions like "Use that name anyway?" answer Yes
After installing perl itself, you will need to install the STAR required module.
The modules are installed using a bundle script (install_perlmods located in /afs/rhic.bnl.gov/star/common/bin/). It needs some work to get it generalized but the idea is that it contains the dependencies and installation order . To install, you can do the following (we assume install_perlmods is in the path for simplicity and clarity):
- first chose a work place where you would unpack the needed modules. Let's assume this is /home/xxx/myworkplace
- Check things out by running install_perlmods with arguments 0 as follow
% install_perlmods 0 /home/xxx/myworkplace
It will tell you the list of modules you need to unpack. If they are already unpacked and /home/xxx/myworkplace contains all needed package directories, skip to step 4. - You can unpack manually OR use the command
% install_perlmods 1 /home/xxx/myworkplace
to do this automatically. Note that you could have skipped step 2 and do that from the start (if confident enough). - The steps above should have created a file named /home/xxx/myworkplace/perlm-install-XXX.csh where XXX is the OS you are working on. Note that the same install directory may therefore be used for ALL platform on your cluster. However, versionning is not (yet) supported.
Execute this script after checking its content. It will run (hopefully smoothly) the perl Makerfile.PL and make / make install commands. Note that you could have also used
% install_perlmods 2 /home/xxx/myworkplace
and skip step 2 & 3. In this mode, it unpacks and proceeds with compilation. To do only if you have absolute blind faith in the process (I don't and have written those scripts ;-) ).
Very old note [this used to happen with older perl version]: if typing make, you get the following message
make: *** No rule to make target `<command-line>', needed by `miniperlmain.o'. Stop.
then you bumped into an old gcc/perl build issue (tending to come back periodically depending on message formats of gcc) and can resolve this by a using any perl version available and running the commands:
% make depend
% perl -i~ -nle 'print unless /<(built-in|command.line)>/' makefile x2p/makefile
This will suppress from the makefile the offending lines and will get you back on your feet.
After you install perl, and your setup is local (in /opt/star) you may want to do the following
% cd /opt/star % ln -s $STAR_HOST_SYS/* . % % # prepare for later directories packages will create % ln -s $STAR_HOST_SYS/share . % ln -s $STAR_HOST_SYS/include . % ln -s $STAR_HOST_SYS/info . % ln -s $STAR_HOST_SYS/etc . % ln -s $STAR_HOST_SYS/libexec . % ln -s $STAR_HOST_SYS/qt . % ln -s $STAR_HOST_SYS/jed . %
While some of those directories will not yet exist, this will create a base set of directories (without the additional compiler / OS version) supporting future upgrades via the "default" set of directories. In other words, any future upgrade of compilers for example leading to a different $STAR_HOST_SYS will still lead as well to a functional environment as far as compatibility exists. Whenever compatibility will be broken, you will need of course to re-create a new $STAR_HOST_SYS tree.
At this stage, you should install as much of the libraries in $OPTSTAR and re-address the perl modules later as some depends on installed libraries necessary for the STAR environment to be functional.
Others/ [PLEASE READ, SOME PACKAGE MAY HAVE EXCEPTION NOTES]
Needed on Other platform (but there on Linux). Unless specified
otherwise, the packages were build with the default values.
make-3.80
tar-1.13
flex-2.5.4
xpm-3.4k
libpng-1.0.9
mysql-3.23.43 on Solaris
mysql-3.23.55 starting from True64 days (should be tried as
an upgraded version of teh API)
BEWARE mysql-4.0.17 was tried and is flawed.
We also use native distribution MySQL
mysql-4.1.22 *** IMPORTANT *** Actually this was an upgrade
on SL4.4 (not necessary but the default 4.1.20
has some bugs)
<gcc-2.95.2>
dejagnu-1.4.1
gdb-5.2
texinfo-4.3
emacs-20.7
findutils-4.1
fileutils-4.1
cvs-1.11 -- perl is needed before hand as it folds
it in generated scripts
grep-2.5.1a Started on Solaris 5.9 in 2005 as ROOT would complain
about too old version of egrep
This may be needed if not installed on your system. It is part of a needed
autoconf/automake deployment.
m4-1.4.1
autoconf-2.53
automake-1.6.3
Linux only
valgrind-2.2.0
valgrind-3.2.3 (was for SL 4.4 until 2009)
valgrind-3.4.1 SL4.4
General/ The installed packages/sources for diverse
software layers. The order of installation was
ImageMagick-5.4.3-9 On RedHat 8+, not needed for SL/RHE but see below
ImageMagick-6.5.3-10 Used on SL5 as default revision is "old" (6.2.8) - TBC
slang-1.4.5 On RedHat 8+, ATTENTION: not needed for SL/RHE, install RPM
lynx2-8-2
lynx2-8-5 Starting from SL/RHE
xv-3.10a-STAR Note the post-fix STAR (includes patch and 32/64 bits
support Makefile)
nedit-5.2-src ATTENTION: No need on SL/RHE (installed by default) [+]
pythia5
pythia6
text2c
icalc
dejagnu-1.4.1 Optional / Dropped from SL3.0.5
gdb-5.1.91 For RH lower versions - Not RedHat , 8+
gdb-6.2 (patched) Done for SL3 only (do not install on others)
gsl-1.13 Started from SL5 and back ported to SL4
gsl-1.16 Update for SL6
chtext
jed-0.99-16
jed-0.99.18 Used from SL5+
jed-0.99.19 Used in SL6/gcc 4.8.2 (no change in instructions)
qt-x11-free-3.1.0
qt-x11-free-3.3.1 Starting with SL/RHE [+]
qt-x11-opensource-4.4.3 Deployed from i386_sl4 and i386_sl305 (after dropping SL3.0.2), SL5
qt-everywhere-opensource-src-4.8.5
Deployed from SL6 onward
qt-everywhere-opensource-src-4.8.7
Deployed on SL6/gcc 4.8.2 (latest 4.8.x release)
doxygen-1.3.5
doxygen-1.3.7 Starting with SL/RHE
doxygen-1.5.9 Use this for SL5+ - this package has a dependence in qt
Installed native on SL6
Python 2.7.1 Started from SL4.4 and onward, provides pyROOT support
Python 2.7.5 Started from SL6 onward, provides pyROOT support
pyparsing V1.5.5 SL5 Note: "python setup.py install" to install
pyparsing V1.5.7 SL6 Note: "python setup.py install" to install
setuptools 0.6c11 SL5 Note: sh the .egg file to install
setuptools 0.9.8 SL6 Note: "python setup.py install" to install
MySQL-python-1.2.3 MySQL 14.x client libs compatible
virtualenv 1.9 SL6 Note: "python setup.py install" to install
Cython-0.24 SL6 Note: "python setup.py build ; python setup.py install"
pyflakes / pygments {TODO}
libxml2 Was used only for RH8.0, installed as part of SL later [+]
libtool-1.5.8 This was used for OS not having libtool, Use latest version.
libtool-2.4 Needed under SL5 64 bits kernel (32 bits code will not assemble
otherwise). This was re-packaged with a patch.
Coin-3.1.1 Coin 3D and related packages
Coin-3.1.3 ... was used for SL6/gcc 4.8.2 + patch
(use the package named Coin-3.1.3-star)
simage-1.7a
SmallChange-1.0.0a
SoQt-1.5.0a
astyle_1.15.3 Started from SL3/RHE upon user request
astyle_1.19 SL4.4 and above
astyle_1.23 SL5 and above
astyle_2.03 SL6 and above
unixODBC-2.2.6 (depend on Qt) Was experimental Linux only for now.
unixODBC-2.3.0 SL5+, needed if you intend to use DataManagement tools
MyODBC-3.51.06 Was Experimental on Linux at first, ignore this version
MyODBC-3.51.12 Version for SL4.4 (needed for mysql 4.1 and above)
mysql-connector-odbc-3.51.12 <-- Experimental package change - new name starting from 51.12. BEWARE.
mysql-connector-odbc-5.x SL5+. As above, only if you intend to use Data Management tools
boost Experimental and introduced in 2010 but not used then
boost_1_54_0 SL6+ needed
log4cxx 0.9.7 This should be general, initial version
log4cxx 0.10.0 Started at SL5 - this is now from Apache
apr-1.3.5 and depend on the Apache Portable Runtime (apr) package
apr-util-1.3.7 which need to be installed BEFORE log4cxx and in the order
expat-1.95.7 showed
valkyrie-1.4.0 Added to SL3 as a GUI companion to valgrind (requires Qt3)
Not installed in SL5 for now (Qt4 only) so ignore
fastjet-2.4.4 Started from STAR Library version SL11e, essentially for analysis
fastjet-3.0.6 SL6 onward
unuran-1.8.1 Requested and installed from SL6+
LHAPDF-6.1.6 Added after SL6.4, gcc 4.8.2
In case you have problems
emacs-24.3 Installed under SL6 as the default version had font troubles
vim-7.4 Update made under SL6.4, please prefer RPM if possible
Not necessary (installed anyway)
chksum
pine4.64 Added at SL4.4 as removed from base install at BNL
Retired
xemacs-21.5.15 << Linux only -- This was temporary and removed
Other directories are
WorkStation/ contains packages such as OpenAFS or OpenOffice Linux
WebServer/ mostly perl modules needed for our WebServer
Linux/ Linux specific utilities (does not fit in General) or
packages tested under Linux only.
Some notes about packages :
Most of them are pretty straight forward to install (like ./configure
make ; make install (changing the base path /usr/local to $OPTSTAR).
With configure, this is done using either
./configure --prefix=$OPTSTAR
./configure --prefix=$XOPTSTAR
Specific notes follows and include packages which are NOT yet official
but tried out.
- Beware that the Msql-Mysql-modules perl module requires a hack
I have not quite understood yet how to make automatic (the
advertized --blabla do not seem to work) on platforms supporting
the client in OPTSTAR
INC = ... -I$(XOPTSTAR)/include/mysql ...
H_FILES = $(XOPTSTAR)/include/mysql/mysql.h
OTHERLDFLAGS = -L$(XOPTSTAR)/lib/mysql
LDLOADLIBS = -lmysqlclient -lm -lz
- GD-2+
Do NOT select support for animated GIF. This will fail on standard
SL distributions (default gd lib has no support for that).
Really easy to install (usual configure / make / make install) but however, the PerlMagick part should be installed separatly (the usual perl module way i.e. cd to the directory, perl Makefile.PL and make / make install). I used the distribution's module. Therefore, that perl-module is not in perl/Installed/ as the other perl-modules. The copy of PerlMagick to /bin/ by default will fail so you may want to additionally do
% make install-info % make install-data-html
which comes later depending on version.
- lynx2-8-2 / lynx2-8-5
Note: First, I tried lynx2-8-4 and the make file / configure
is a real disaster. For 2-8-2/2-8-5, follow the notes
below
General :
% ./configure --prefix=$XOPTSTAR {--with-screen=slang}
Do not forget to
% make install-help
% make install-doc
caveat 1 -- Linux (lynx 2-8-2 only, fixed at 2-8-5)
$OPTSTAR/lib/lynx.cfg was modified as follow
96,97c96,97
< #HELPFILE:http://www.crl.com/~subir/lynx/lynx_help/lynx_help_main.html
< HELPFILE:file://localhost/opt/star/lib/lynx_help/lynx_help_main.html
---HELPFILE:http://www.crl.com/~subir/lynx/lynx_help/lynx_help_main.html
#HELPFILE:file://localhost/PATH_TO/lynx_help/lynx_help_main.html
For using curses (needed under Linux, otherwise, the screen looks funny),
one has to do a few manipulation by hand i.e.
. start with ./configure --prefix=$XOPTSTAR --with-screen=slang
. edit the makefile and add -DUSE_SLANG to SITE_DEFS
. change CPPFLAGS from /usr/local/slang to $OPTSTAR/include [when slang is local]
Version 2-8-5 has this issue fixed.
. Change LIBS -lslang to -L$OPTSTAR/lib -lslang
. You are ready now
There is probably an easier way but as usual, I gave up after close
to 15mnts reading, as much struggle and complete flop at the end ..
caveta 2 -- Solaris/True64 :
We did not build with slang but native (slang screws colors up)
Those packages can be assembled simply by using the following command:
% make clean && make install PREFIX=$OPTSTAR
To build a 32 bits versions of the executable under a 64 bits kernel, use
- text2c: % make CC=`which gcc` CFLAGS="-lfl -m32"
- icalc: % make CC=`which gcc` CFLAGS="-lm -m32"
- chksum: % make CC=`which gcc` CFLAGS="-m32 -trigraphs"
- chtext: % make CC=`which gcc` CFLAGS="-lfl -m32"
This package distributed already patched and in principle, only a few 'make' commands should suffice. Note
- xv is licensed so the usage as to remain stricly for your users' amusement only. If you use this package for doing any work, you are violating the law. Please, read the license agreement at http://www.trilon.com/xv/pricing.html
Normal build
Now, you should be ready to build the main program (I am not sure why some depencies fail on some platform and did not bother to fix).
% cd tiff/ % make clean && make % cd ../jpeg % make clean && make % cd .. % rm -f *.o && make % make -f Makefile.gcc64 install BINDIR=$OPTSTAR/bin
For 32 bits compilation under a 64 bits kernel
% cd tiff/ % make clean && make CC=`which gcc` COPTS="-O -m32" % cd ../jpeg % make clean && make CC=`which gcc` CFLAGS="-O -I. -m32" LDFLAGS="-m32" % cd .. % rm -f *.o && make -f Makefile.gcc32 % make -f Makefile.gcc32 install BINDIR=$OPTSTAR/bin
Makefile.gcc32 and Makefile.gcc64 are both provided for commodity.
Building from scratch (good luck)
However, if you need to re-generate the makefile (may be needed for new architectures), use
% xmkmf
Then, the patches is as follow
% sed "s|/usr/local|$OPTSTAR|" MakeFile >Makefile.new % mv Makefile.new Makefile
and in xv.h, line 119 becomes
# if !defined(__NetBSD__) && ! defined(__USE_BSD)
After xmkmf, you will need to
% make depend
before typing make. This may generate some warnings. Ignore then.
However, I had to fix diverse caveats depending on situations ...
Caveat 1 - no tiff library found
Go into the tiff/ directory and do
% cd tiff % make -f Makefile.gcc % cd ..
to generate the mkg3states (itself creating the g3states.h file) as it did not work.
Caveat 2 - tiff and gcc 4.3.2 in tiff/
With gcc 4.3.2 I created an additional .h file named local_types.h and force the definition of a few of the u_* types but using define statements (I know, it is bad). The content of that file is as follows
#ifndef _LOCAL_TYPES_ #define _LOCAL_TYPES_ #if !defined(u_long) # define u_long unsigned long #endif #if !defined(u_char) # define u_char unsigned char #endif #if !defined(u_short) # define u_short unsigned short #endif #if !defined(u_int) # define u_int unsigned int #endif #endif
and it needs to be included in tiff/tif_fax3.h and tiff/tiffiop.h .
Caveat 3 -- no jpeg library?
In case you have a warning about jpeg such as No rule to make target `libjpeg.a', do the following as well:
% cd jpeg % ./configure % make % cd ..
There is no install provided. I did
% make linux % cp source/nc source/nedit $OPTSTAR/bin/ % cp doc/nc.man $OPTSTAR/man/man1/nc.1 % cp doc/nedit.man $OPTSTAR/man/man1/nedit.1
Other targets
% make dec % make solaris
If you need to build for another compiler or another platform, you may want to copy one of the provided makefile and modify them to create a new target. For example, if you have a 64 bits kernel but want to build a 32 bits nedit (for consistency or otherwise), you could do this:
% cp makefiles/Makefile.linux makefiles/Makefile.linux32
then edit and add -m32 to bothe CFLAGS and LIBS. This will add a target "platform" linux32 for a make linux32 command (tested this and worked fine). The STAR provided package added (in case) both a linux64 and a linux32 reshaped makefile to ensure easy install for all kernels (gcc compiler should be recent and accept the -m flag).
The unpacking is "raw". So, go in a working directory where the .tar.gz are, and do the following (for linux)
% test -d Pythia && rm -fr Pythia ; mkdir Pythia && cd Pythia && tar -xzf ../pythia5.tar.gz % ./makePythia.linux % mv libPythia.so $OPTSTAR/lib/ % cd .. % % test -d Pythia6 && rm -fr Pythia6 ; mkdir Pythia6 && cd Pythia6 && tar -xzf ../pythia6.tar.gz % test -e main.c && rm -f main.c % ./makePythia6.linux % mv libPythia6.so $OPTSTAR/lib %
Substitute linux with solaris for Solaris platform. On Solaris, Pythia6 requires gcc to build/link.
On SL5, 64 bits note
Depending on whether you compile a native 64 bit library support or a cross-platform 32/64, you will need to handle it differently.
For a 64 bits platform, I had to edit the makePythia.linux and -fPIC to the options for a so the binaries main.c . I did not provide a patched package mainly because v5 is not really needed in STAR. For pythia6 caveat: On SL5, 64 bits, use makePythia6.linuxx8664 file. You will need to chmod +x first as it was not executable in my version.
On 64 bit platform to actually build a cross-platform version, I had instead to use the normal build but make sure to add -m32 to compilation and linker options and -fPIC to compilation option.
True64
% chmod +x ./makePythia.alpha && ./makePythia.alpha Pythia6
% chmod +x ./makePythia6.alpha && ./makePythia6.alpha
The following script was used to split the code which was too big
#!/usr/bin/env perl
$filin = $ARGV[0];
open(FI,$filin);
$idx = $i = 0;
while( defined($line = <FI>) ){
chomp($line); $i++;
if ($i >= 500 && $line =~ /subroutine/){
$i = 0;
$idx++;
}
if ($i == 0){
close(FO);
open(FO,">$idx.$filin");
print "Opening $idx.$filin\n";
}
print FO "$line\n";
}
close(FO);
close(FI);
Starts the same than Qt3 i.e. assuming that SRC=/afs/rhic.bnl.gov/star/common/General/Sources/ and $x and $y stands for major and minor versions of Qt. There are multiple flavors of the package name (it was called qt-x11-free* then qt-x11-opensource* and with more recent package qt-everywhere-opensource-src*). For the sake of instructions, I provide a generic example with the most recent naming (please adapt as your case requires). WHEREVER is a location of your choice (not the final target directory).
% cd $WHEREVER % tar -xzf $SRC/qt-everywhere-opensource-src-4.$x.$y.tar.gz % cd qt-everywhere-opensource-src-4.$x.$y % ./configure --prefix=$XOPTSTAR/qt4.$x -qt-sql-mysql -no-exceptions -no-glib -no-rpath
To build a 32/64 bits version on a 64 bits OS or forcing a 32 bits exec (shared mode) on a 32 bits OS, use a configure target like the below
% ./configure -platform linux-g++-32 -mysql_config $OPTSTAR/bin/mysql_config [...] % ./configure -platform linux-g++-64 [...]
Note that the above assumes you have a proper $OPTSTAR/bin/mysql_config. ON a mixed 64/32 bits node, the default in /usr/bin/mysql_config will return the linked library as the /usr/lib64/mysql path and not the /usr/lib/mysql and hence, Qt make will fail finding the dependencies necessary to link with -m32. The trick we had was to copy mysql_config and replace lib64 by lib and voila!.
Compiling
% make % make install % cd $OPTSTAR % ln -s qt4.$x ./qt4
For compiling with a different compiler, note that the variables referenced in this section will be respected by configure. You HAVE TO do this as the project files and other configuration files from Qt will include information on the compiler (inconsistency may arrise otherwise).
Misc notes
- If you use the same directory tree for compiling the 64 bits and the 32 bits version, please note that 'make clean' will not do the proper job. You will need to use a more systematic % find . -name '*.o' -exec rm -f {} \; command before running ./configure again.
- We added mysql support in Qt4 and Qt can now be compiled in a separate directory and installed properly (at last!). If the mysql support gives you trouble on a 64 bit OS attempting to build a 32 bit image, be sure you have used as indicated above the -mysql_config /usr/lib/mysql/mysql_config option as otherwise, the default mysql_config will be picked from /usr/bin and that version will refer to the 64 bits libraries (the link will then fail).
- For SL44, we created a qt3 distribution as then, both 3 and 4 existed. Otherwise, the ./qt4 link as indicated above is sufficient for SL5 and above.
- On some systems (SL3.0.2 for sure), I also used
- -no-openssl as there were include problems with ssl.h and krb5.h
- -qt-libtiff as the default system included header did not agree with Qt code
- -platform linux-icc could be used for icc based compiler
Horribly packaged, the easiest is to unpack in $OPTSTAR, cd to qt-x11-free-3.X.X (where X.X stands for the current sub-version deployed on our node), run the configure script, make the package, then make clean. Then, link
% cd $OPTSTAR && ln -s qt-x11-free-3.X.X qt
Later release can be build that way with changing the soft-link without removing the preceeding version entirely. Before building, do the following (if you had previous version of Qt installed). This is not necessary if you install the package the first time around. Please, close windows after compilation to ensure STAR path sanity.
% cd $OPTSTAR/qt
% setenv QTDIR `pwd`
% setenv LD_LIBRARY_PATH `pwd`/lib:$LD_LIBRARY_PATH
% setenv PATH `pwd`/bin:$PATH
To configure the package, then use one of:
- Linux gcc: ./configure --prefix=`pwd` -no-xft -thread
- Linux icc: ./configure --prefix=`pwd` -no-xft -thread -platform linux-icc
- True64 : ./configure --prefix=`pwd` -no-xft -thread
- Solaris: ./configure --prefix=`pwd` -no-xft
In case of thread, the regular version is build first then the threaded version (so far, they have different names and no Soft links).
You may also want to edit $QTDIR/mkspecs/default/qmake.conf and replace the line
QMAKE_RPATH = -Wl,-rpath,
by
QMAKE_RPATH =
By doing so, you would disable the rpath shared library loading and rely on LD_LIBRARY_PATH only for loading your Qt related libraries. This has the advantages that you may copy the Qt3 libraries along your project and isolate onto a specific machine without the need to see the original installation directory.
% ./configure --prefix=$XOPTSTAR [CC=icc CXX=icc] % make clean # in case you are re-using the same directory for multiple platform % make % make install
Use the environment variables noted in this section and all will go well.
Note on versions earlier than 2.3.0 (including 2.2.14 previously suggested)
The problem desribed below DOES NOT exist if you use 32 bits kernel OS and is specific to 64 bits kernel with 32 bits support.
For a 32 bits compilation under a 64 bits kernel, please use % cp -f $OPTSTAR/bin/libtool . after the ./configure and before the make (see this section for an explaination of why). unixODBC versions 2.3.0 does not have this problem.
Older version
Came with sources and one could compile "easily" (and register manually).
- MyODBC
Linux % ./configure --prefix=$XOPTSTAR --with-unixODBC=$XOPTSTAR [CC=icc CXX=icc]
Others % ./configure --prefix=$XOPTSTAR --with-unixODBC=$XOPTSTAR --with-mysql-libs=$XOPTSTAR/lib/mysql
--with-mysql-includes=$XOPTSTAR/include/mysql --with-mysql-path=$XOPTSTAR
Note : Because of an unknown issue, I had to use --disable-gui on True64
as it would complain about not finding the X include ... GUI is
not important for ODBC client anyway but whenever time allows ...
Deploy instructions at http://www.mysql.com/products/myodbc/faq_toc.html
Get the proper package, currently named mysql-connector-odbc-5.x.y-linux-glibc2.3-x86-32bit or mysql-connector-odbc-5.x.y-linux-glibc2.3-x86-64bit. the package are available from the MySQL Web site. The install will need to be manual i.e.
% cp -p bin/myodbc-installer $OPTSTAR/bin/ % cp -p lib/* $OPTSTAR/lib/ % rehash
To register the driver, use the folowing command
% myodbc-installer -d -a -n "MySQL ODBC 5.1 Driver" -t "DRIVER=$OPTSTAR/lib/libmyodbc5.so;SETUP=$OPTSTAR/lib/libmyodbc3S.so" % myodbc-installer -d -a -n "MySQL" -t "DRIVER=$OPTSTAR/lib/libmyodbc5.so;SETUP=$OPTSTAR/lib/libmyodbc3S.so"
this will add a few lines in $OPTSTAR/etc/odbcinst.ini . The myodbc-installer -d -l does not seem to be listing what you installed though (but the proper lines will be added to the configuration).
Installation would benefit from some smoothing + note the space between the --prefix and OPTSTAR (non standard option set for configure).
Use one of
% ./configure --prefix $OPTSTAR # for general compilation % ./configure --platform linux-32 --prefix $OPTSTAR # Linux, gcc 32 bits - this option was added in the STAR package % ./configure --platform linux-64 --prefix $OPTSTAR # Linux, gcc 64 bits - this option was fixed in the STAR package
then
% make % make install
as usual but also
% make docs
which will fail d ue to missing eps2pdf program. Will create however the HTML files you will need to copy somewhere.
% cp -r html $WhereverTheyShouldGo
and as example
% cp -r html /afs/rhic.bnl.gov/star/doc/www/comp/sofi/doxygen
Note: The linux-32 and linux-64 platform were packaged in the archive provided for STAR (linux-32 does not exists in the original doxygen distribution while linux-64 is not consistent with -m64 compilation option).
Starting from SL5, we also deployed the following: coin, simage, SmallChange, SoQt. Those needs to be installed before Qt4 but after doxygen. All options are specified below to install those packages. Please, substitute -m32 by -m64 for a 64 bits native support. After the configure, the usual make and make install is expected.
The problem desribed below DOES NOT exist if you use 32 bits kernel OS and is specific to 64 bits kernel with 32 bits support.
For the 32 bits version compilation under a 64 bits kernel and for ALL sub-packages below, please be sure you have the STAR version of libtool installed and use the command
% cp -f $OPTSTAR/bin/libtool .
after the ./configure to replace the generated local libtool script. This will correct a link problem which will occur at link time (see the libtool help for more information).
% ./configure --enable-debug --disable-dependency-tracking --enable-optimization=yes \ --prefix=$XOPTSTAR CFLAGS="-m32 -fPIC -fpermissive" CXXFLAGS="-m32 -fPIC -fpermissive" LDFLAGS="-m32 -L/usr/lib" \ --x-libraries=/usr/lib
or, for or the 64 bits version
% ./configure --enable-debug --disable-dependency-tracking --enable-optimization=yes \ --prefix=$XOPTSTAR CFLAGS="-m64 -fPIC -fpermissive" CXXFLAGS="-m64 -fPIC -fpermissive" LDFLAGS="-m64"
simage (needs Qt installed and QTDIR defined prior):
% ./configure --prefix=$XOPTSTAR --enable-threadsafe --enable-debug --disable-dependency-tracking \ --enable-optimization=yes --enable-qimage CFLAGS="-m32 -fPIC" CXXFLAGS="-m32 -fPIC" \ LDFLAGS="-m32" FFLAGS="-m32 -fPIC" --x-libraries=/usr/lib
or, for the 64 bits version
% ./configure --prefix=$XOPTSTAR --enable-threadsafe --enable-debug --disable-dependency-tracking \ --enable-optimization=yes --enable-qimage CFLAGS="-m64 -fPIC" CXXFLAGS="-m64 -fPIC" \ LDFLAGS="-m64" FFLAGS="-m64 -fPIC"
% ./configure --prefix=$XOPTSTAR --enable-threadsafe --enable-debug --disable-dependency-tracking \ --enable-optimization=yes CFLAGS="-m32 -fPIC -fpermissive" CXXFLAGS="-m32 -fPIC -fpermissive" \ LDFLAGS="-m32" FFLAGS="-m32 -fPIC"
or, for the 64 bits version
% ./configure --prefix=$XOPTSTAR --enable-threadsafe --enable-debug --disable-dependency-tracking \ --enable-optimization=yes CFLAGS="-m64 -fPIC -fpermissive" CXXFLAGS="-m64 -fPIC -fpermissive" \ LDFLAGS="-m64" FFLAGS="-m64 -fPIC"
./configure --prefix=$XOPTSTAR --enable-threadsafe --enable-debug --disable-dependency-tracking \ --enable-optimization=yes --with-qt=true --with-coin CFLAGS="-m32 -fPIC -fpermissive" CXXFLAGS="-m32 -fPIC -fpermissive" \ LDFLAGS="-m32" FFLAGS="-m32 -fPIC"
or, for the 64 bits version
./configure --prefix=$XOPTSTAR --enable-threadsafe --enable-debug --disable-dependency-tracking \ --enable-optimization=yes --with-qt=true --with-coin CFLAGS="-m64 -fPIC -fpermissive" CXXFLAGS="-m64 -fPIC -fpermissive" \ LDFLAGS="-m64" FFLAGS="-m64 -fPIC"
Flex is usually not needed but some OS have pre-GNU flex not adequate so I would recommend to deploy flex-2.5.4 anyway (the latest version since Linux 2001). Do not install under Linux if you have flex already on your system as rpm.
Attention: Under SL5 64 bits, be sure you have flex32libs-2.5.4a-41.fc6 installed as documented on Scientific Linux 5.3 from 4.4. Linkage of 32 bits executable would otherwise dramatically fail.
- Xpm (Solaris) % xmkmf % make Makefiles % make includes % make I ran the install command by hand changing the path (cut and paste) Had to % cd lib % installbsd -c -m 0644 libXpm.so $OPTSTAR/lib % installbsd -c -m 0644 libXpm.a $OPTSTAR/lib % cd .. % cd sxpm/ % installbsd -c sxpm $OPTSTAR/bin % cd ../cxpm/ % installbsd -c cxpm $OPTSTAR/bin % Onsolaris, the .a was not there, add to % cd lib && ar -q libXpm.a *.o && cp libXpm.a $OPTSTAR/lib % cd .. Additionally needed % if ( ! -e $OPTSTAR/include) mkdir $OPTSTAR/include % cp lib/xpm.h $OPTSTAR/include/ - libpng ** Solaris ** % cat scripts/makefile.solaris | sed "s/-Wall //" > scripts/makefile.solaris2 % cat scripts/makefile.solaris2 | sed "s/gcc/cc/" > scripts/makefile.solaris3 % cat scripts/makefile.solaris3 | sed "s/-O3/-O/" > scripts/makefile.solaris2 % cat scripts/makefile.solaris2 | sed "s/-fPIC/-KPIC/" > scripts/makefile.solaris3 % % make -f scripts/makefile.solaris3 will eventually fail related to libucb. No worry, this can be sorted out (http://www.unixguide.net/sun/solaris2faq.shtml) by including /usr/ucblib in the -L list % cc -o pngtest -I/usr/local/include -O pngtest.o -L. -R. -L/usr/local/lib \ -L/usr/ucblib -R/usr/local/lib -lpng -lz -lm % make -f scripts/makefile.solaris3 install prefix=$OPTSTAR ** True64 ** Copy the make file but most likely, a change like ZLIBINC = $(OPTSTAR)/include ZLIBLIB = $(OPTSTAR)/lib in the makefile is neeed. pngconf.h and png.h needed for installation and either .a or .a + .so cp pngconf.h png.h $OPTSTAR/include/ cp libpng.* $OPTSTAR/lib - mysql client (Solaris) % ./configure --prefix=$XOPTSTAR --without-server {--enable-thread-safe-client} (very smooth) The latest option is needed to create the libmysqlclient_r needed by some applications. While this so is build with early version of MySQL, version 4.1+ requires the configure option explicitly. - dejagnu-1.4.1 [Solaris specific]
the install program was not found.
% cd doc/ && cp ./runtest.1 $OPTSTAR/man/man1/runtest.1
% chmod 644 $OPTSTAR/man/man1/runtest.1
The basic principles is as usual
% ./configure --prefix=$OPTSTAR % make % make xjed % make install
However, on some platform (but this was not seen as a problem on SL/RHE), you may need to apply the following tweak before typing make. Edit the configure script and add $OPTSTAR (possibly /opt/star) to it as follow.
JD_Search_Dirs="$JD_Search_Dirs \
$includedir,$libdir \
/opt/star/include,/opt/star/lib \
/usr/local/include,/usr/local/lib \
/usr/include,/usr/lib \
/usr/include/slang,/usr/lib \
/usr/include/slang,/usr/lib/slang"
32 / 64 bit issue?
The problem desribed below DOES NOT exist if you use 32 bits kernel OS and is specific to 64 bits kernel with 32 bits support.
The variables described here will make configure pick up the right comiler and compiler options. On our initial system, the 32 bits compilation under the 64 bits kernel Makefile tried to do something along the line of -L/usr/X11R6/lib64 -lX11 but did not find X11 libs (since the path is not adequate). To correct for this problem, edit src/Makefile and replace XLIBDIR = -L/usr/lib64 by XLIBDIR = -L/usr/lib . You MUST have the 32 bits compatibility libraries installed on your 64 bits kernel for this to work.
AIX
I had to make some hack on AIX (well, who wants to run on AIX in the first place right ?? but since AIX do not have any emacs etc ... jed is great) as follow
- make a copy of unistd.h and comment the sleep() prototype
- modify file.c to include the local version (replace <> by "")
- modify main.c to include sys/io.h (and not io.h) and comment out direct.h
Voila (works like a charm, don't ask).
emacs
Version 24.3
In the below options, I recommend the with-x-toolkit=motif as the default GTK will lead to many warnings depending on the user's X11 server version and supported features. Motif may create an "old look and feel" but will work. However, you may have a local fix for GTK (by installing all required modules and dependencies) and not need to go to the Motif UI.
% ./configure --with-x-toolkit=motif --prefix=$OPTSTAR
For the 32 bits version supporting 64/32 bits, use the below
% ./configure --with-crt-dir=/usr/lib --with-x-toolkit=motif --prefix=$OPTSTAR CFLAGS="-m32 -fPIC" CXXFLAGS="-m32 -fPIC" LDFLAGS="-m32"
Then the usual 'make' and 'make install'.
Below are old instructions you should ignore
- emacs
Was repacked with leim package (instead of keeping both separatly)
in addition of having a patch in src/s/sol2.h for solaris as follow
#define HAVE_VFORK 1
#endif
+/* Newer versions of Solaris have bcopy etc. as functions, with
+ prototypes in strings.h. They lose if the defines from usg5-4.h
+ are visible, which happens when X headers are included. */
+#ifdef HAVE_BCOPY
+#undef bcopy
+#undef bzero
+#undef bcmp
+#ifndef NOT_C_CODE
+#include <strings.h>
+#endif
+#endif
+
Nothing to do differently here. This is just a note to keep track
of changes found from community mailing lists.
% ./configure --prefix=$OPTSTAR --without-gcc
- Xemacs (Solaris)
% ./configure --without-gcc --prefix=$OPTSTAR
Other solution, forcing Xpm
% ./configure --without-gcc --prefix=$OPTSTAR --with-xpm --site-prefixes=$OPTSTAR
Possible code problem :
/* #include <X11/xpm.h> */
#include <xpm.h>
- gcc-2.95 On Solaris was used as a base compiler
% ./configure --prefix=$OPTSTAR
% make bootstrap
o Additional gcc on Linux
Had to do it in multiple passes (you do not need to do the first pass
elsewhere ; this is just because we started without a valid node).
A gcc version < 2.95.2 had to be used. I used a 6.1 node to assemble
it and install in a specific AFS tree (cross version)
% cd /opt/star && ln -s /afs/rhic/i386_linux24/opt/star/alt .
Move to the gcc source directory
% ./configure --prefix=/opt/star/alt
% make bootstrap
% make install
install may fail in AFS land. Edit gcc/Makefile and remove "p" option
to the tar options TAROUTOPTS .
For it work under 7.2, go on a 7.2 node and
% cp /opt/star/alt/include/g++-3/streambuf.h /opt/star/alt/include/g++-3/streambuf.h-init
% cp -f /usr/include/g++-3/streambuf.h /opt/star/alt/include/g++-3/streambuf.h
... don't ask ...
o On Solaris, no problems
% ./configure --prefix=/opt/star/alt
etc ...
- Compress-Zlib-1.12 --> zlib-1.1.4
If installed in $OPTSTAR,
% setenv ZLIB_LIB $OPTSTAR/lib
% setenv ZLIB_INCLUDE $OPTSTAR/include
- findutil
Needed a patch in lib/fnmatch.h for True64
as follow :
+ addition of defined(__GNUC__) on line 49
+ do a chmod +rw lib/fnmatch.h first
#if !defined (_POSIX_C_SOURCE) || _POSIX_C_SOURCE < 2 || defined (_GNU_SOURCE) || defined(__GNUC__)
* CLHEP1.8 *** Experimental only ***
printVersion.cc needs a correction #include <string> to <string.h>
for True64 which is a bit strict in terms of compilation.
On Solaris, 2 caveats
o gcc was used (claim that CC is used but do not have the include)
o install failed running a "kdir" command instead of mkdir so do a
% make install MKDIR='mkdir -p'
Using icc was not tried and this package when then removed.
- mysqlcc
./configure --prefix=$OPTSTAR --with-mysql-include=$OPTSTAR/include/mysql --with-mysql-lib=$OPTSTAR/lib/mysql
The excutable do not install itself so, one needs to
% cp -f mysqlcc $OPTSTAR/bin/
First, please note that the package distributed for STAR contains a patch for support of the 32 / 64 bits environment. If you intend to download from the original site, please apply the patch below as indicated. If you do not use our distributed package and attempt to assemble a 32 bits library under a 64 bits kernel, we found cases where the default libtool will fail.
Why the replacement of libtool? Sometimes, "a" version of libtool is added along software packages indicated in this help. However, those do not consider the 32 bits / 64 bits mix and often, their use lead to the wrong linkage (typical problem is that a 32 bits executable or shared library is linked against the 64 bits stdc++ versions, creating a clash).
This problem does not existswhen you assemble a 64 bits code under a 64 bits kernel or assemble a 32 bits codes under a 32 bits kernel.
In all cases, to compile and assemble, use a command line like the below:
% ./configure --prefix=$XOPTSTAR CFLAGS="-m32 -fPIC" CXXFLAGS="-m32 -fPIC" \ FFLAGS="-m32 -fPIC" FCFLAGS="-m32 -fPIC" LDFLAGS="-m32" # 32 bits version % ./configure --prefix=$XOPTSTAR CFLAGS="-m64 -fPIC" CXXFLAGS="-m64 -fPIC" \ FFLAGS="-m64 -fPIC" FCFLAGS="-m64 -fPIC" LDFLAGS="-m64" # 64 bits version % make % make install
Patches
libtool 2.4
The file ./libltdl/config/ltmain.sh needs the following patch
<
< # JL patch 2010 -->
< if [ -z "$m32test" ]; then
< #echo "Defining m32test"
< m32test=$($ECHO "${LTCFLAGS}" | $GREP m32)
< fi
< if [ "$m32test" != "" ] ; then
< dependency_libs=`$ECHO " $dependency_libs" | $SED 's% \([^ $]*\).ltframework% -framework \1%g' | $SED 's|lib64|lib|g'`
< else
< dependency_libs=`$ECHO " $dependency_libs" | $SED 's% \([^ $]*\).ltframework% -framework \1%g'`
< fi
< # <-- end JL patch
<
---
dependency_libs=`$ECHO " $dependency_libs" | $SED 's% \([^ $]*\).ltframework% -framework \1%g'`
in gdb/linux-nat.c
/*
fprintf_filtered (gdb_stdout,
"Detaching after fork from child process %d.\n",
child_pid);
*/
and go (no, I will not explain).
Version 2.03
% cd astyle_2.03/src
% make -f ../build/gcc/Makefile CXX="g++ -m32 -fPIC" # for the 64 bits version, use the same command
# with CXX="g++ -m64 -fPIC"
% cp bin/astyle $XOPTSTAR/bin/
% test -d $XOPTSTAR/share/doc/astyle || mkdir -p $XOPTSTAR/share/doc/astyle
% cp ../doc/*.* $XOPTSTAR/share/doc/astyle
The target
% make -f ../build/gcc/Makefile clean
also works fine and is needed between versions.
Version 1.23
Directory structure changes but easier to make the package so use instead
% cd astyle_1.23/src/ % make -f ../buildgcc/Makefile CXX="$CXX $CFLAGS" % cp ../bin/astyle $OPTSTAR/bin/ % cd ..
Note that the compressed command above assumes you have define dthe envrionment variables as described in this section. Between OS (32 / 64 bits) you may need to % rm -f obj/* as the make system will not reocgnize the change between kernels (you alternately may make -f ../buildgcc/Makefile clean but a rm will be faster :-) ).
Documentation
A crummy man page was added (will make it better later if really important). It was generted as follow and provided for convenience in the packages for STAR (do not overwrite because I will not tell you what to do to make the file a good pod):
% cd doc/ % lynx -dump astyle.html >astyle.pod
[... some massage beyond the scope of this help - use what I provided ...]
% pod2man astyle.pod >astyle.man % cp astyle.man $OPTSTAR/man/man1/astyle.1
Versions < 1.23
Find where the code really unpacks. There are no configure for this package.
% cd astyle_1.15.3 ! or
% cd astyle/src
% make
% cp astyle $OPTSTAR/bin/
Version 1.15.3
The package comes as a zip archive. Be aware that unpacking extracts files in the current directory. So, the package was remade for convenience. Although written in C++, this executable will perform as expected under icc environment. On SL4 and for versions, gcc 3.4.3, add -fpermissive to the Makefile CPPFLAGS.
MUST be installed using $XOPTSTAR because there is an explicit reference to the install path. Copying to a local /opt/star would therefore not work. For icc, use the regular command as this is a self-contained program without C++ crap and can be copied from gcc/icc directory. The command is
% ./configure --prefix=$XOPTSTAR
Note: valgrind version >= 3.4 may ignore additional compiler options (but will respect the CC and CXX variables) as it will assemble both 32 bits and 64 bits version on a dual architecture platform. You could force a 32 build only by adding the command line options --enable-only32bit.
Caveats for earlier revisions below:
Version 2.2
A few hacks were made on the package, a go-and-learn experience as problems appeared
coregrind/vg_include.h
123c123
< #define VG_N_RWLOCKS 5000
---
#define VG_N_RWLOCKS 500
coregrind/vg_libpthread.vs
195a196
> __pthread_clock_gettime; __pthread_clock_settime;
to solve problems encountered with large programs and pthread.
The problem desribed below DOES NOT exist if you use 32 bits kernel OS and is specific to 64 bits kernel with 32 bits support.
For a 32 bits compilation under a 64 bits kernel, please use % cp -f $OPTSTAR/bin/libtool . after the ./configure and before the make (see this section for an explaination of why) for both the apr and expat packages.
apr is an (almost) straight forward installation:
% ./configure --prefix=$OPTSTAR
apr-util needs to have one more argument i.e.
% ./configure --prefix=$OPTSTAR --with-apr=$OPTSTAR
The configure script will respect the environment variables described in this section and, provided you have defined them properly for the intended target (32 or 64 bits executable), the resulting Mkaefile will be properly generated without further modifications needed.
Note however that the package distributed in STAR has one hack to the fconfigure script a follows (apply if you download from anoher source than STAR's distributed packages):
% diff configure.orig configure
4255c4255,4256
< CFLAGS="-g -O2"
---
> # CFLAGS="-g -O2"
> CFLAGS="-g -m32"
4261c4262,4263
< CFLAGS="-O2"
---
> # CFLAGS="-O2"
> CFLAGS="-m32"
This will allow another way to assemble the package (without having to define the env variables) but you will need to substitute -m32 by -m64 as appropriate.
% ./configure --prefix=$OPTSTAR
log4cxx 0.10.x
This distribution is part of the Apache project and requires APR library (see above).
The package was taken nearly as-is apart from the following patches:
- inputstreamreader.cpp, socketoutputstream.cpp, console.cxx - requires adding #include <string.h> on top as memmove, mencpy are no longer implicit but declared in string.h
After installing APR and using the patches as indicated, use
% ./configure --prefix=$XOPTSTAR --with-apr=$XOPTSTAR CFLAGS="-m32 -fPIC" CXXFLAGS="-fno-inline -g -m32" LDFLAGS="-m32"
or
% ./configure --prefix=$XOPTSTAR --with-apr=$XOPTSTAR CFLAGS="-m64 -fPIC" CXXFLAGS="-fno-inline -g -m64" LDFLAGS="-m64"
% cp -f $OPTSTAR/bin/libtool .
% make
% make install
Please do NOT forget to use % cp -f $OPTSTAR/bin/libtool . after the ./configure and before the make (see this section for an explaination of why). This assummes you installed libtool as instructed.
Finally, there is one patch needed if you download the package from other sources than where STAR provides the packages. The patch relates to a problem with atomic operations handling.
Index: src/main/cpp/objectimpl.cpp
===================================================================
--- src/main/cpp/objectimpl.cpp (revision 654826)
+++ src/main/cpp/objectimpl.cpp (working copy)
@@ -36,12 +36,12 @@
void ObjectImpl::addRef() const
{
- apr_atomic_inc32( & ref );
+ ref++;
}
void ObjectImpl::releaseRef() const
{
- if ( apr_atomic_dec32( & ref ) == 0 )
+ if ( --ref == 0 )
{
delete this;
}
log4cxx 0.9.5
There is a bug on Linux so, start with commenting all lines related to HAVE_LINUX_ATOMIC_OPERATIONS in configure.in before the below. Finally, two code had to be patched are now repacked
- filewatchdog.cpp line 21: comment #ifdef WIN32 and the associated #endif
- cocketimpl.cpp line 41: add #include <errno.h>
For ODBC support, one needs
% setenv CPPFLAGS "-I$XOPTSTAR/include" % setenv LDFLAGS "-L$XOPTSTAR/lib"
log4cxx 0.9.7
Also need to do the below or it will not even find the libs at configure.
% setenv CPPFLAGS "-I$XOPTSTAR/include" % setenv LDFLAGS "-L$XOPTSTAR/lib"
On Scientific Linux 4.4 aka Linux 2.6 replace as follows
#AC_CHECK_FUNCS(gettimeofday ftime setenv) AC_CHECK_FUNCS(setenv)
Linux 7.3 distributions note
On Version 7.3 of Linux, this is hard to install. You will need to upgrade m4, autoconf to at the least the versions specified for "other platforms". It won't compile easily with gcc 2.96 though. But it can using
% ./configure --prefix=$OPTSTAR CC=/usr/bin/gcc3 CXX=/usr/bin/g++3
if you have all gcc 3 ready.
Finally, if you install log4cxx from a new Linux version (especially one having a different version of autoconf tools), you better start from a fresh directory and not attempt to use the 'clean' target (it will fail).
Summay then:
Linux gcc (general instructions, all log4cxx)
% ./autogen.sh % ./configure --prefix=$OPTSTAR [--with-ODBC=unixODBC]
Linux icc
% setup icc % ./configure --prefix=$XOPTSTAR CC=icc CXX=icc [--with-ODBC=unixODBC]
If icc is the second target, you should use 'make clean' before the configure.
Solaris
Does not configure (need the autoconf tools)
True64
Not tried yet
Platform: so far needed to update RH 8.0 only, add to propagate to other platform in 2006 due to a component dependence issue.
% ./configure --without-python --prefix=$XOPTSTAR
Re-added at BNL since SL4.4 because it was removed from the base installation, this may not be needed for your site (install from RPM, it exists).
Scientific Linux (don't get fooled by the targets)
% ./build lrh % cp bin/pine bin/pico $OPTSTAR/bin/
On a mixed of 32 / 64 bits architecture and/or with alternate gcc versions, the command examples below could be used:
% ./build lrh CC=`which gcc` SSLDIR=/usr/include/openssl/ EXTRALDFLAGS="-m32" EXTRACFLAGS="-m32 -fPIC" [or] % ./build lrh CC=`which gcc` SSLDIR=/usr/include/openssl/ EXTRALDFLAGS="-m64" EXTRACFLAGS="-m64 -fPIC"
GSL - GNU Scientific Library
The install is straight forward with the usual configure but on 64 bit machine, you will need to add the CCFLAGS and LDFLAGS as showed below
% ./configure --prefix=$OPTSTAR ! default bits % ./configure --prefix=$OPTSTAR CFLAGS="-m32 -fPIC" LDFLAGS="-m32" ! 32 bits % ./configure --prefix=$OPTSTAR CFLAGS="-m64 -fPIC" LDFLAGS="-m64" ! 64 bits % make % make install
The below were fine with verison 2.7.1
% setenv BASECFLAGS "-m32 -fPIC" % setenv CXXFLAGS "-m32 -fPIC" % setenv LDFLAGS "-m32" % ./configure --prefix=$XOPTSTAR
On a mixed architecture, I had to modify the generated pyconfig.h as the use of VA_LIST_IS_ARRAY would get pythong to crash.
1069c1069 < //#define VA_LIST_IS_ARRAY 1 --- > #define VA_LIST_IS_ARRAY 1
For the 64 bits version, please substitute -m32 with -m64 as follows
% setenv BASECFLAGS "-m64 -fPIC" % setenv CXXFLAGS "-m64 -fPIC" % setenv LDFLAGS "-m64" % ./configure --prefix=$XOPTSTAR
Note: The default compilation (without using the environment variable setting) may succeed but binding with ROOT and other package will fail and require -fPIC and additionally, it is best to have in all configurations -m32/-m64 specified explicitely.
Build is straight forward in principle i.e.
% python setup.py build % python setup.py install
but
- on a mixed 32/64 bits platform, the 32 bits will need to be persuaded by
- editing site.cfg and setting mysql_config to the 32 bit version (likely /usr/lib/mysql/mysql_config ) - you can be sure of this as the return value for --cflags would have -m32
- Add the following code in setup_posix.py
65,68d64 < for i in range(len(extra_compile_args)): < if extra_compile_args[i] == '-m32': < extra_link_args += ['-m32'] <
I am sure there are other more ellegant ways but this works fine.
- If your default MySQL distribution resides in $OPTSTAR, you will also need to edit the site.cfg script before running the setup script and modify the mysql_config variable accordingly. This will prevent running into symnbol loading conflicts later (usually happening because a third party product would, in this case, use one version of MySQL and STAR code another).
The basic compilation requires
./configure --prefix=$OPTSTAR CXXFLAGS="-m32 -fPIC -fno-inline" CFLAGS="-m32 -fPIC -fno-inline" LDFLAGS="-m32"
For the 64 bits, replace -m32 by -m64. -fno-inline is needed still to circuvnet a gcc bug with inlining.
Certainly, the most helpful reference was this boost reference. But those are not immediate instructions. Here is what you will need to do:
% ./bootstrap.sh --prefix=$XOPTSTAR
In any cases, this will build a few 64 bits executables on a 32/64 bits machine but don't panic yet ... To build, use one of the below (as appropriate):
% ./bjam cflags="-m64 -fPIC" cxxflags="-m64 -fPIC" linkflags="-m64 -fPIC" address-model=64 threading=multi architecture=x86 stage or % ./bjam cflags="-m32 -fPIC" cxxflags="-m32 -fPIC" linkflags="-m32 -fPIC" address-model=32 threading=multi architecture=x86 stage
I am sure you already see the problem - on AMD processors, you may have a different "arhitecture" so we cannot give you the exact instruction to use here. Possible architectures are x86, x86_amd64, x86_ia64, amd64 or ia64.
When you are done wth compiling, execute nearly the same command but instead of "stage" use
% ... install --prefix=$XOPTSTAR
and you will be hopefully done.
unuran
This package follows a typical install i.e.
% ./configure --prefix=$XOPTSTAR CXXFLAGS="-m32 -fPIC" CFLAGS="-m32 -fPIC" LDFLAGS="-m32" or % ./configure --prefix=$XOPTSTAR CXXFLAGS="-m64 -fPIC" CFLAGS="-m64 -fPIC" LDFLAGS="-m64" % make % make install
This will allow ROOT to build the TUnuran classes.
LHAPDF-6.1.6
This package is not straight forward to install. Use the usual initial setup i.e.
./configure --prefix=$XOPTSTAR CXXFLAGS="-m32 -fPIC" CFLAGS="-m32 -fPIC" LDFLAGS="-m32"
or
./configure --prefix=$XOPTSTAR CXXFLAGS="-m64 -fPIC" CFLAGS="-m64 -fPIC" LDFLAGS="-m64"
then the usual
% make
However, before make install, modify lhapdf-config and add -m32 -fPIC (-m64 -fPIC for 64 bits platform) to cflags and -m32 (-m64) to the ldflags i.e.
40c40
< test -n "$tmp" && OUT="$OUT -m32 -fPIC -I${prefix}/include "
---
> test -n "$tmp" && OUT="$OUT -I${prefix}/include "
46c46
< test -n "$tmp" && OUT="$OUT -m32 -L${exec_prefix}/lib -lLHAPDF"
---
> test -n "$tmp" && OUT="$OUT -L${exec_prefix}/lib -lLHAPDF"
as the configure will not do that and hence, not generate a config script suitable for a a mix 32/64 bits.
vim
Configure is standard, use a minimal option set and features=big as below
% ./configure --enable-pythoninterp=yes --enable-perlinterp=yes --enable-cscope --with-features=big \ --prefix=$XOPTSTAR CFLAGS="-m64 -fPIC" CXXFLAGS="-m64 -fPIC" LDFLAGS="-m64"
or
./configure --enable-pythoninterp=yes --enable-perlinterp=yes --enable-cscope --with-features=big \--prefix=$XOPTSTAR CFLAGS="-m32 -fPIC" CXXFLAGS="-m32 -fPIC" LDFLAGS="-m32"
then the usual make and make install.
»
- Printer-friendly version
- Login or register to post comments