CERNLIB on Debian: Frequently Asked Questions

(This page also contains answers to some less-frequently asked questions that I thought people might nevertheless find interesting.)

Contents

0. Introduction

1. Relationship between versions of CERNLIB

2. Compiling and Installing Debian's CERNLIB

3. Specific questions about Debian's version of CERNLIB

4. Miscellaneous

0. Introduction

0.1. What is Debian?

Debian is an entirely free operating system, both in the monetary sense, and more importantly, in the sense that the source code of every program in the system is available for anyone to inspect, modify and distribute. Debian's two great strengths are the seamless ease with which software may be installed and kept updated, and its ability to run on almost any modern CPU family (architecture). Although the kernel of the operating system is currently Linux, there are plans to run Debian with other kernels as well.

For the benefit of people not familiar with Debian, I will briefly mention the versioning scheme. The current stable version of Debian is version 4.0 and is code-named "Etch". The previous stable version was version 3.1, code-named "Sarge". The current testing version of Debian, which will eventually become a new stable version, is code-named "Lenny" and will someday be released as version 5.0. Finally, the development or so-called unstable version of Debian is always code-named "Sid" and has no version number.

0.2. What is CERNLIB?

CERNLIB is a collection of libraries and analysis tools, mainly used by physicists, but potentially useful for anyone doing mathematical analyses. The best-known CERNLIB software packages include MINUIT, a minimization routine; PAW and Paw++, graphical data analysis tools; and GEANT 3, a Monte Carlo package used to predict the behavior of subatomic and nuclear physics detectors. (GEANT 3 has been largely obsoleted by Geant4, which switched from use of FORTRAN to C++. For packages of Geant4, see here.) Related tools include cfortran, a header file for use in C/C++ <-> FORTRAN compatibility, and Mn_Fit, a graphical analysis tool that uses the CERN libraries and in some senses is a competitor with PAW.

1. Relationship between versions of CERNLIB

1.1. Are you allowed to do this? What GPL version is used?

To answer the first question: Yes! In 2000, CERN re-licensed CERNLIB under the GNU General Public License. (Prior to that it was restricted for use only by institutions having some connection with CERN, although in practice this meant almost anyone who wanted it.) This means that anyone may take the source code of CERNLIB, modify it, and distribute the modified source (and optionally, binaries compiled from it), as long as it is clear what the modifications were and who owns copyright on what. Although not receiving nearly as much publicity as, for instance, the release of the original Netscape 5 code, this was a big victory for Free Software advocates.

Since the most recent (2006) upstream release of CERNLIB, a new version of the GNU GPL, version 3, has been released. The CERNLIB licensing page does not explicitly indicate what version of the GPL applies. It does, however, contain a web link to GNU's current GPL version page. We may take this to mean that distributing CERNLIB under the current GPL version, whatever it may be (version 3 as of this writing) is permitted. On the other hand, the CERNLIB upstream source code being redistributed by Debian was downloaded from CERN's web site while the GPL version 2 was still current. Therefore I conclude that redistributing CERNLIB code under GPL version 2 is also allowed.

1.2. How is the Debian-patched version of CERNLIB better than CERN's?

There are numerous improvements over what is distributed by CERN. Some of them are:

1.3. How is the Debian-patched version of CERNLIB worse than CERN's?

There are several ways in which one could argue that CERN's official version of CERNLIB is better. The most obvious is that a number of programs and libraries are missing from the Debian packages of CERNLIB. Some of these are just seldom-used, except perhaps by a few people at CERN (which uses its own RedHat-based Linux distribution), so I saw no reason to package them for Debian. Others would require more effort to fix up until they were suitable for Debian than would be worthwhile. Still others have fundamental licensing problems that potentially make it illegal for anyone to distribute them. These various cases are covered in more detail in questions 3.6 to 3.8.

Sticklers for formal approval procedures will of course prefer the official binaries "blessed" and supported by CERN. Likewise, if compatibility is your paramount concern, you may want to install CERN's binaries rather than risk that bug-fixes for Debian have changed expected behavior, or that the changes to have CERNLIB meet the FHS prevent various third-party programs from working. Remember the tongue-in-cheek Debian warranty: "if it breaks, you get to keep both pieces."

The latest (and apparently final) official CERN version of CERNLIB is the 2006 release. It is available in Debian "lenny" (testing) and "sid" (unstable) distributions.

1.4. How is the Debian version related to other distributions of CERNLIB?

Aside from the official downloads at CERN, there are a number of different versions of CERNLIB floating around on the Internet. Most are distributed only as patches against the official source code. In addition to the versions mentioned in the following question, well-known distributions of CERNLIB include Joseph Comfort's version, Harald Vogt's port to Linux on the AMD64/EM64t and Itanium platforms, and Zhiguo Yao's port to Cygwin.

Until recently, the authors of these different versions haven't collaborated, except for borrowing one another's patches once in a while. The Debian version is by far the most heavily patched relative to what CERN distributes: the Debian-specific packaging and patch directories in Debian's four CERNLIB-related source packages (cernlib, paw, geant321, and mclibs) come to 2.7 megabytes. It now incorporates most patches from most of the other available versions.

Currently the Debian patches do not include the Cygwin port. The Cygwin patches may conceivably be merged in at some time in the future, although my motivation to do so is not high (as they would make no difference in the Debian packages themselves). Furthermore, even if they were merged in, they would not provide any support for, e. g., creating shared libraries (DLLs) under Cygwin.

1.5. Are there native packages of CERNLIB for my non-Debian system?

If you are running Mac OS X, CERNLIB is packaged under Fink by Remi Mommsen, with a small set of patches, mainly to allow the build infrastructure to recognize OS X. The packaging is split up into cernlib, a core set of CERNLIB applications; cernlib-dev, the basic libraries and header files; cernlib-geant321, GEANT 3; cernlib-mclibs, the Monte Carlo libraries; and cernlib-paw++, the Paw++ program. These packages may only be available for OS X on PowerPC-based hardware.

For RPM-based GNU/Linux distributions, you can install some or all of the RPMs being developed by Patrice Dumas (pertusus at free.fr) for Fedora Extras. These are based to a large extent on my patch set, and may be obtained (for instance) by direct download from Fedora's download server, or with YUM following the instructions here. These packages are available for GNU/Linux on the x86 and x86-64 (AMD64/EM64t) architectures. At one point there were also powerpc packages, but Fedora seems to have ended support for that architecture.

Alternately, you may be able to install the "canonical" RPM provided by CERN. This RPM has the disadvantage of containing absolutely everything CERNLIB-related, even source code, so it will use a huge amount of disk space, and you will not be able to pick and choose what you want to install. It includes the libraries and code mentioned in questions 3.7 and 3.8, which suffer from non-free licensing terms. The CERN RPM is also provided only for x86 GNU/Linux.

Note that if you want to take advantage of the Debian patches to CERNLIB, you can compile the Debian version by following the steps in question 2.5, although of course this will not produce the native package format for your system.

2. Compiling and Installing Debian's CERNLIB

Of course, for all of the questions in this section about "How do I compile/install CERNLIB", one possible answer is to use the official binaries or source code available from CERN. See also CERN's instructions for installing from source. However, if you've read this far, presumably you want to use the Debian-patched versions, either for better integration with a Debian (or Debian-based) operating system, or for the improvements described in question 1.2 of this FAQ. So, read on.

2.1. How can I install CERNLIB on Debian?

The CERNLIB packages for sarge / etch / lenny / sid are official Debian packages, and available from your usual Debian mirror with "apt-get install cernlib". See the packages page for a complete list of individual packages; you may be able to save disk space by only installing the parts of CERNLIB you specifically need. In particular, if you only want to do data analysis with PAW or Paw++, just run "apt-get install paw" (or paw++).

2.2. How can I compile CERNLIB on Debian?

Just like any other source package on Debian. First, as root, install the packages required to build CERNLIB:

apt-get install build-essential fakeroot
apt-get build-dep cernlib

Then, reverting to a normal user, cd into a working directory and download the Debianized CERNLIB source:

apt-get source cernlib
cd cernlib-*

If you want to add additional compiler flags to the build process, edit debian/rules and add them to the declaration of the LOCAL_DEFINES Make variable.

At this point, you will find one directory "upstream" containing tarballs of CERN's pristine source code (except with some files removed for licensing reasons), and another directory "debian" containing patches and packaging data for Debian. First make sure that everything is properly cleaned and prepared:

fakeroot debian/rules clean

To unpack the source code and apply the patches without compiling, run the following:

fakeroot debian/rules patch

If you aren't interested in inspecting or modifying the patched source code, instead proceed straight to the build:

fakeroot debian/rules binary

This step will take between one hour and a few days, depending upon your processor speed. At the end, you will find a number of .deb files in your initial working directory. You can then install them with "dpkg -i *.deb" (if you don't want to install all of them, be careful of dependencies).

Recent versions of CERNLIB, available in Etch, Lenny and Sid, have been split apart into four separate source packages. Thus, after running the above, you will need to similarly apt-get source for paw, geant321, and mclibs source packages. (You may omit any that you don't care about.) Follow similar steps to those above for each source package. Note that each depends upon the cernlib libraries and binaries already having been installed. In addition, building the geant321 source package requires paw libraries to have already been installed.

2.3. How can I install CERNLIB on Debian woody?

[Obsolete; redacted.]

2.4. How can I compile CERNLIB on Debian woody?

[Obsolete; redacted.]

2.5. How can I install / compile CERNLIB with Debian patches on a non-Debian system?

This is a little more complicated since you won't have any Debian infrastructure tools. You will need the two files cernlib_2006.dfsg.2.orig.tar.gz and cernlib_2006.dfsg.2-13.diff.gz. Having downloaded these files to a working directory, run the following commands:

gunzip -c cernlib_2006.dfsg.2.orig.tar.gz | tar xf -
gunzip -c cernlib_2006.dfsg.2-13.diff.gz | patch -p0
cd cernlib-2006.dfsg.2.orig
cp debian/add-ons/Makefile ./Makefile

As in question 2.2, you have the possibility of examining the unpacked and patched source code before compiling by running the optional command:

make patch

Otherwise, proceed to the build (note that as of this version of CERNLIB, you may need to build with gfortran!) ...

make
make install

The last step must of course be done as root. The contents of the README and INSTALL files in the directory cernlib-2006.dfsg.2.orig/debian/add-ons may be useful to read (they contain information about build-time dependencies, for instance) before the compile step.

If you want to compile with specific compiler flags, pass them to make in the LOCAL_DEFINES Make variable every time you invoke it: make LOCAL_DEFINES="-m64 -some -more -flags" (for patch, all, and install targets).

This procedure has been tested and verified only on GNU/Linux and Mac OS X operating systems.

Recent versions of CERNLIB have been split apart into four separate source packages. Thus, after running the above, you will need to similarly obtain source code for the paw, geant321, and mclibs source packages. (You may omit any that you don't care about.) Follow similar steps to those above to build each source package. Each of these depends upon the cernlib binaries and libraries already being installed; in addition, geant321 code depends upon the paw libraries already being installed.

2.6. Are there any special build flags I should know about?

There are several build flags you may find useful in debugging or speeding up compile time. To set any of these build flags, even on a non-Debian system, put them in the environment variable $DEB_BUILD_OPTIONS before running the build. For instance, assuming you use an sh-compatible shell,

export DEB_BUILD_OPTIONS=noopt,nostrip,nospdf ; make

2.7. Why does the build output not show any compiler flags?

The compiler flags are stripped from stdout so that a build log of CERNLIB will not grow to outrageous size. (Excessively large logs cause trouble for Debian's automatic build machines.) If the compiler encounters an error in some source file, the full compiler command will be printed for that file before the build halts, so you are not missing anything important. If you want to see all compiler flags anyway, delete the patch file

cernlib-2006.dfsg.2/debian/patches/603-trim-build-output.dpatch

and comment it out in the file 00list in the same directory, before running any of the patch or compile steps shown in questions 2.2 or 2.5.

3. Specific questions about Debian's version of CERNLIB

3.1. How should I file a bug?

The Debian Project has a web page about reporting bugs; please become familiar with it. The best tool for filing bugs in Debian is "reportbug". If you can't or don't want to use it for some reason, you can submit bug reports via email as described on the bug reporting web page. If the bug is in PAW or Paw++, you can also execute the "kuip/bugreport" command or "Help->Mail Paw++ Developers" menu option, respectively, from within those programs. (I suggest you not fill in the "Phone number" field, since the bug report will become publicly accessible once submitted to Debian.) Finally, you could email me directly at <kmccarty@debian.org>, but I would prefer you to use one of the other methods so there is a public record of the bug.

You can look at the list of known bugs in the Debian BTS for CERNLIB (see also the lists for paw, mclibs, geant321) to see if your bug has already been reported by someone else. See also my to-do list and the quality assurance page for the official packages in sid.

A large proportion of bugs filed against CERNLIB turn out to result from compiler optimization bugs. If it seems like this might be the case with your bug (for instance, inexplicable crashes or output of wrong results), it would be very helpful to me if you could recompile CERNLIB, turning off all optimization; install the resulting .debs; and see whether the bug still occurs. See questions 2.6 and 2.2 for instructions on how to do this. Even if the bug then no longer occurs, please report it so I can figure out which source file the compiler is mangling. Examples of helpful bug reports of this nature include bug #290394 and bug #324902. As usual, the more information you provide, the faster I will be able to fix the bug.

Finally, if the bug is in something not actually in Debian, for instance the montecarlo-installer-data package, go ahead and email me directly.

3.2. How do I deal with programs wanting a value for $CERN, etc.?

In accordance with Section 9.9 of Debian Policy, no program supplied by Debian will depend upon environment variables other than the usual suspects like $HOME, etc. For third-party software, normally it is sufficient to set three environment variables as follows:

export CERN=/usr
export CERN_LEVEL=.
export CERN_ROOT=/usr

You will have to add these to your shell initialization files (.bashrc, .zshrc, or whatever) yourself. If your shell is csh or tcsh, you will instead need the lines

setenv CERN /usr
setenv CERN_LEVEL .
setenv CERN_ROOT /usr

This should satisfy most programs. Some build infrastructures may require a little additional tweaking to work.

If this isn't sufficient, in Etch, Lenny and Sid there is also a script named install-cernlib-dirs.sh in the examples directory of the cernlib-base Debian package. Running this script as root will install a skeleton /cern directory structure and populate it with symlinks to the FHS-compatible contents of the CERNLIB Debian packages. The script is fully documented in the cernlib-base README.Debian file.

Feel free to email me if you can't get something to work.

3.3. What is the deal with shared libraries?

CERN does not support building shared (dynamic) libraries from CERNLIB, only static ones. However, shared libraries are very nice for the reasons mentioned in question 1.2, so the Debian source has been patched to create them. As an added benefit, this makes for much smaller binaries.

To keep people who develop with CERNLIB from becoming confused, the rewritten cernlib script in Debian has the default behavior of linking programs against CERNLIB libraries statically, but against other libraries dynamically. This reproduces the behavior seen with CERN's version of CERNLIB (mainly because CERN's CERNLIB includes no shared libraries).

If you instead want to make your application link completely dynamically (as is done by CERNLIB programs in Debian), use the -dy flag to cernlib. For instance:

g77 -o myapp myapp.F `cernlib -dy packlib mathlib`

If you want to make your application statically linked against not only CERNLIB, but also against all other libraries, you will want the cernlib script's -safe flag and the compiler's -static flag:

g77 -static -o mystaticapp myapp.F `cernlib -safe packlib mathlib` -lncurses

If you are interested in technical details, the -dy and -safe flags actually do the same thing: they prevent Debian's cernlib script from surrounding its output of CERNLIB libraries with the linker flags -Wl,-static ... -Wl,-dy. The -dy and -safe flags are of course unknown to the version of the cernlib script supplied by CERN.

Finally, I should note that parts of CERNLIB are broken on 64-bit machines in such a way that the brokenness is only apparent when using shared libraries, whereas a statically linked application may appear to work (or even actually work) correctly. See question 4.1 for more information.

3.4. Why doesn't my application using COMIS in Pawlib work?

This answer only applies to some 32-bit machines. If you are using a 64-bit machine in 64-bit mode, please instead see the answer to question 4.1.

Making COMIS work when linked dynamically was the most difficult problem to resolve in getting CERNLIB shared libraries to work correctly. As a result, the solution I settled on is a bit of a hack. The details of the problem, and the technical issues that forced this solution, are described in the README.Debian for the libpawlib2-dev package (in Sarge, the package was known as libpaw1-dev). Without going into detail, you need to do one of the following:

1) You can link your program statically against libpawlib (which is the default action if you are linking with the cernlib dependency script) and all should be well with no special effort required.

2a) If you are linking dynamically against libpawlib and your executable's main source code file is written in FORTRAN, it should include the preprocessor directive

#include <comis/mdpool.inc>

immediately after the "      PROGRAM programname" line.

2b) If you are linking dynamically against libpawlib and your executable's main source code file is written in C or C++, it should include the preprocessor directive

#include <comis/mdpool.h>

at the top of the source code.

It is only necessary for one file of your source code to include mdpool.inc or mdpool.h, and may in fact cause linking problems if more than one file does so. Do not include mdpool.inc or mdpool.h in a header file unless that file is itself only #include'd by one source file. Finally, if you are writing an application intended to be portable, be aware that mdpool.h only exists in Debian's version of CERNLIB.

3.5. Where are zftp / pawserv / zserv?

You probably installed the "cernlib" metapackage with "apt-get install cernlib". Because zftp, pawserv and zserv seem so unlikely to be used by most people, and because there are potential security issues involved with using them, they are not depended upon by the cernlib metapackage. You can, however, obtain them by installing the "cernlib-extras" metapackage, or by installing the "zftp" and "pawserv" packages directly.

Note that pawserv (the remote PAW file server) and zserv (the ZFTP daemon) run as root; accept passwords in cleartext; and, as far as I know, have never been audited for security. For these reasons, you would be insane to install the pawserv package (containing both pawserv and zserv daemons) unless ports 345 and 346 are blocked from all but trusted machines. This could be done by using iptables, with the /etc/hosts.allow config file, or by running on a private LAN, for instance.

Note also that by default, only the pawserv daemon is run. To change this default, you can either reconfigure the package with "dpkg-reconfigure -plow pawserv", or else edit /etc/inetd.conf directly.

If you have a good reason to install one of these programs, you know a lot more about them than I do, so please give me feedback about the Debian packaging of them.

3.6. Where are patchy / fatmen / hepdb / kuesvr?

kuesvr is part of the Debian package libpacklib1 (renamed to libpacklib1-gfortran in Sid following the g77 to gfortran transition).

Patchy (and its successors ypatchy and nypatchy) is an ancient set of programs that acted as a combination preprocessor and revision control system. They apparently developed more or less independently of diff, patch, rcs, and related Unix utilities. The program available in the latest CERNLIB releases is nypatchy (Patchy version 5). There is now an nypatchy .deb available in Sid.

Patrice Dumas (pertusus at free.fr) over at Fedora has obtained a copy of the Patchy 4 (ypatchy) source code, and determined how to compile it. (It's fun to see a source tarball with files having timestamps from 1994. The Patchy 4 bootstrap process is also quite bizarre.) I have asked CERNLIB upstream about the licensing status of Patchy 4 but have never received an answer. If it proves to be freely distributable, I may distribute unofficial .debs of it from this web site. I am unlikely to upload it into the official Debian archive due to its archaic nature (Patchy 4 isn't even Y2K compliant), but you're welcome to email me and try to change my mind.

For the other applications, either I could not find out enough about them to package them for Debian in a reasonable way, or I didn't think it was worth the effort to do so. You can get them individually from CERN's site (here, for instance), statically linked so that they should work on any i386-based GNU/Linux system.

FATMEN, the File And Tape Management system, and HEPDB, the High Energy Physics Data Base, are no trouble to compile; however, documentation about how to set them up properly is lacking. At one point I had produced experimental Debian packages of these two systems, but they no longer are installable with the current set of CERNLIB packages. If you use FATMEN or HEPDB and you want to see Debian support them correctly, get in touch with me. In the meantime, you can obtain the executables by building CERNLIB from source (see question 2.2) and looking in the "cernlib-<version>/bin" directory when the build is complete.

Several other programs and libraries can be found in the set of binaries and libraries distributed by CERN -- for instance, Phase, Space, libSpin.a. I have no idea where these originated; they do not appear in the CERNLIB source code. They no longer seem to exist in the CERNLIB 2006 binary directories.

3.7. Where did all the Monte Carlo libraries go?

The Monte Carlo libraries Ariadne, Fritiof, Jetset, Lepto, and Pythia could not be packaged for Debian because they are either not freely licensed, or else depend on things that are not freely licensed. See the non-free page for more information, and how to get these libraries for Debian.

3.8. Where is the GEANT-FLUKA code?

The FLUKA routines have been removed from the packages of GEANT 3.21 available here. They are not freely licensed, and the versions included in the CERNLIB source tree were obsolete. The FLUKA authors were rather unhappy that some published articles did not distinguish between current FLUKA code, and the GEANT-FLUKA routines that the authors wanted to withdraw as early as 1996. Please see the section of the FLUKA FAQ titled Relations with other particle transport codes; the relevant question is (at this writing) the second on that page. For current FLUKA libraries, please see the website http://www.fluka.org. As far as I know, source code is NOT available.

3.9. Why does my GEANT program not compile / abort with an error?

It is possible that you depend upon the Jetset library, which is not freely licensed and so cannot be distributed by Debian. This will affect you if you want to use one of the GEANT functions or subroutines GLUDKY GLUND GLUNDI. You can install a Debian package of Jetset by following directions on the non-free page.

Another possibility is that you depend upon one of the functions from the GEANT-FLUKA code, which had to be removed from Debian's distribution of CERNLIB for similar reasons. See the previous question.

The FLUKA functions and subroutines that were removed are as follows:

BBRCH AINEL AKEKA ALTRA ALTRAF AMGA ANKEKA BAMJEV BEEXI BEKEKA BERTTP BETA BETARN BETRST BIMSEL BKEKA BKLASS BNKEKA CALUMO CALUMV CHANWT COREVT CORRIN COSLEG DATAR3 DECAUX DECAY DIFEVV DOST DRELAB DRES EEXI EEXLVL EKEKA ENERGI ENERGY ENRG ERUP EVDEEX EVENTV EVEVAP EVVINI FDEVAP FDNOPT FDPREE FEKFNC FEREVV FERHAV FISFRA FKDECA FKDRES FKENER FKERUP FKFLAV FKIMPU FKSIGI FKVERT FKZERO FLAVOR FLDIST FLINIT FLKDT1 FLKDT2 FLKDT3 FLKDT4 FLKDT5 FLKDT6 FLKDT7 FLUFIN FPFRNC FPOWER FPROB FRADNC FRHINC FRHONC GAMRN GETA GFMDIS GFMFIN HADDEN HADEVV HADRIN HADRIV HEVHIN HINHEV HKLASS HYPERO IEFUN IMPULS INCINI INDEX2 KINPAR KPOIS LORTRA NCLVIN NCLVST NIZL NIZLNW NUCEVV NUCNUC NUCREL NUCRIV NUDISV NUPREL NWISEL PARJET PEANUT PFNCLV PHDSET PHDWLL PIOABS PMPRAB POLI PREPRE QNRG RACO RAKEKV RBKEKV RCHANV ROTAT RSTSEL SAMCST SBCOMP SFECFE SHPTOT SIGEL SIGFER SIGINT SIHAEL SITSAO STALIN TCHOIC THREPD TRAFO TRAHAD TRANS TTRANS TWOPAD TWOPAR UMOFIN VEREIN VERTEX XINNEU XINPRO XLAMB XSENEU XSEPRO ZEROIN

Additionally, GFTMAT may try to call FLDIST and/or FLINIT, resulting in an abnormal program exit, depending on how it is set up. A likely way for this to happen before version 1:3.21.14-4 of the Debian package is if you try to plot cross sections for a particle traveling through matter using any of the FLUKA mechanisms 'HADF', 'INEF', 'ELAF'. Before version 1:3.21.14-2 of the Debian packages, it would also happen if you tried to plot cross sections with 'ALL' mechanisms.

Unlike Jetset, there is no canonical distribution site for GEANT-FLUKA other than the CERNLIB source code, so I cannot write an installer package for it. (Nor would I want to do so, since the original authors of GEANT-FLUKA wish that it would cease to exist.) If you need it, you will have to download CERN's version of the GEANT library, for instance libgeant321.a, and put it in (for instance) /usr/lib. To prevent confusion you may first want to uninstall the Debian packages of libgeant321-2 and libgeant321-2-dev. Make sure NOT to uninstall the packages they depend upon! For upstream's version of libgeant321.a to work properly you will need to keep the geant321-data package installed, to create a symlink /usr/lib/xsneut95.dat -> /usr/share/geant321-data/xsneut95.dat, and to run your GEANT 3.21 programs in an environment with $CERN_ROOT set to "/usr".

Note: On Sarge you should instead download the 2004 version of libgeant321.a. Also, the Debian packages to uninstall would be named libgeant1 and libgeant1-dev.

3.10. Why is the Debian-packaged CERNLIB documentation lacking?

CERN has not explicitly issued any statement about the licensing of the rich set of documentation available on its web site. Without such a statement, Debian has no permission to distribute any of that documentation. Even if we assumed that CERN intended to release these docs under the same license (the GPL) as CERNLIB itself, Debian still could not distribute the docs because there is no LATEX source code available for the PostScript or latex2html-generated HTML files, but the GPL requires that redistributors make available the "preferred form of the work for making modifications to it".

Instead, only the limited documentation available in text or LATEX source form as part of the CERNLIB source code, explicitly licensed under the GPL, can be distributed. What documentation does exist in Debian can be found in the packages geant321-doc (a plain text version of the GEANT 3.21 documentation), paw-demos (some example demos and tests of PAW), and files in the /usr/share/doc/package directories of some of the Monte Carlo library packages. In addition, most of the non-free Monte Carlo libraries available via an installer package come with some LATEX documentation that you can choose to build into HTML and PostScript.

Here are direct links to some particularly useful CERNLIB documents, roughly organized by software collection:

GEANT 3.21

PAW and Pawlib

The Packlib and graphical library references below may also be useful; see a diagram of PAW components.

Graphical drawing libraries

Packlib

This is the CERNLIB fundamental library, composed of several rather miscellaneous modules:

Mathlib

The Mathlib library routines are mainly documented in CERN's "short write-ups". Some old sets of functions are only documented in the "old long write-ups", available in electronic form only as scanned copies of the originals, from the bottom half of the documentation intro page.

Monte Carlo and miscellaneous physics libraries

3.11. Why do the contents of my PAW/Paw++/Mn_Fit graphical window disappear?

This is also a frequently asked question on the official site for PAW. Basically, these applications use the "backing store" of the X server to redraw the graphics window. Hence this capability of the X server must be turned on, which is not the case by default. Any of the possibilities described at that FAQ entry should solve the problem.

Be warned that use of the backing store may adversely affect the performance of your X server. Additionally, customizing /etc/X11/XF86Config-4 or xorg.conf, as one of the solutions suggests, will cause Debconf to refuse to update your X server settings. See the entry for "How do the XFree86 packages manage their non-conffile configuration files..." in the X Strike Force FAQ for more information. It is hoped that in the future (post-Etch), the X maintainers will implement a /etc/X11/xorg.conf.d/ directory where individual packages may drop this sort of setting in order for the backing store to be turned on automatically; see the XSF's Lenny roadmap.

3.12. Why does my Paw++ or GEANT 3.21 browser window GUI seem not fully functional?

The symptom in question is that the graphical browser window does not have any of the following widgets: the current PATH window and list of object types in the file browser (right below the menu bar); the names of the objects selected in the class and object windows (at the bottom); and the Clone and Close buttons at bottom right. That is, it looks like this rather than like this.

There is a bug in one of the CERNLIB graphical libraries (libpacklib-lesstif, to be specific) that causes it not to set certain fallback X11 application defaults for these applications, including geometric values that control the appearance of the missing widgets, in some cases. Specifically, this happens when a Paw++ (or in the case of GEANT 3.21, Geant++) file exists (even if it is empty!) in one of the directories /etc/X11/app-defaults/ or /usr/lib/X11/app-defaults/. As a workaround, you can copy one or both of these files, which include the necessary geometric specifications, into the directory /etc/X11/app-defaults/ on your machine: Paw++, Geant++. Other X11 app-defaults that may be set for Paw++ may be found here.

This bug should be fixed in recent versions of the paw-common and geant321 packages, in Etch or newer. (Note, if you only installed libgeant321-2-dev, you should also install geant321!) However, you may still encounter it if you had installed earlier versions of those packages, modified their configuration files, and later upgraded, telling dpkg to keep your old versions of the files.

The presence of other minor bugs in the GUI would not surprise me. They likely result from the fact that Paw++, etc. are built against Lesstif on Debian rather than Motif. If you find these issues intolerable, please consider trying to create patches for Lesstif to make it work better, trying to convince the Open Group to change the license of OpenMotif to something GPL-compatible, or trying to convince the Lesstif project to rename themselves "Harmony".

4. Miscellaneous

4.1. What is the status of CERNLIB on 64-bit?

As of the October 2004 release of cernlib, it includes limited 64-bit support in some libraries. See this changelog for specifics. Parts of CERNLIB as shipped by upstream are still very broken on 64-bit architectures because the CERNLIB source implicitly assumes sizeof(int) is greater than or equal to sizeof(void *) by storing pointers as integers. Fixing this problem correctly would involve a massive rewrite, taking by my estimate at least one or two man-months of work and probably breaking library ABI/API and also file format compatibility. The two major problem areas:

  1. ZEBRA memory banks, used by the histogramming package HBOOK, use 32-bit integers to store pointer locations.
  2. The COMIS Fortran interpreter uses 32-bit integers to store pointer locations.

The person upstream who has done most of the 64-bit porting work so far is Ian Mclaren (mclareni at mail.cern.ch) - you might contact him to ask if there is a realistic chance of ZEBRA and COMIS being fixed in a proper way.

Harald Vogt (hvogt at ifh.de) has written an additional, quite large patch that allows PAW and Paw++ to pass all of their demos and tests on AMD64/EMT64 and Itanium 64-bit machines. The patch is available from this location. Harald's patch is not yet included (and may never be) in upstream CERNLIB, whose maintainer feels the patch may be too intrusive. It is also a set of incredibly ugly hacks (note that this observation is in no way intended to diminish the magnitude of the work that the patch required!)

Nevertheless, this patch is included in the most recent Debian versions of CERNLIB, in addition to a small additional patch I wrote adding Digital Alpha support, so the new Debian packages of PAW and Paw++ on 64-bit arches should work more or less correctly. Because of the way it was implemented, if you build your own programs against CERNLIB libraries, you may find that some things work better on 64-bit machines if you compile against the static libraries instead of the shared libraries. (This has in fact been done with the paw and paw++ packages for 64-bit architectures shipped by Debian).

4.2. Does CERNLIB work on architecture X?

I only have firsthand knowledge of a few systems. It certainly works under GNU/Linux on 32-bit Intel-compatible ("i386") and IBM PowerPC architectures, as these platforms are explicitly supported by CERN. The most recent version of PAW in Debian passes all the PAW tests on the AMD64 platform. I have also done minimal testing of PAW under GNU/Linux on SPARC (32-bit userspace) and Motorola 680x0 ("m68k") platforms, where things seem OK at least on a first look. (Whether anyone sane would want to run CERNLIB on m68k machines is a question I chose not to explore.)

For what it's worth, so far all of the architectures that have built the gfortran-based version of CERNLIB have had it successfully pass the test suite.

4.3. Can you package ROOT / Geant4 / EGS / Physica?

For the last two of these, the short answer is No. For the first two, read on. The last three of these are all released under non-free licenses, and some have other licensing problems or ambiguities too. Like much software written by physicists, some of them are also in really poor shape with respect to build and installation infrastructures. (See this list of offenses for more detail.)

ROOT

ROOT authors have kindly released ROOT 5.08 and later versions under the Library GPL. They deserve major thanks and kudos from all of us for doing so. Christian Holm Christensen (cholm at nbi.dk), who is also a regular ROOT contributor, intends to package it for Debian, and indeed his unofficial packages are already available at http://mirror.phy.bnl.gov/debian-root/. Be warned that there may not be a smooth upgrade path from these unofficial packages to the official ones that eventually make it into the Debian archive.

To state explicitly what is perhaps obvious, the following line should be added to /etc/apt/sources.list in order to install these unofficial packages via apt-get or aptitude.

deb http://mirror.phy.bnl.gov/debian-root/ unstable root

Replace "unstable" with "stable" as needed. See also the ROOT pages on the Debian Wiki for more information.

Geant4

In the case of Geant4, I've grown tired of the obnoxious compilation process and I have finally generated Debian packages of it. Please see the DebianScience/Geant4 wiki page for more information.

Others

The rest of these I do not really use; so I am not interested in trying to hack these applications into a shape suitable for inclusion into Debian when they cannot be included in it. I only wrote an installer package for the non-free Monte Carlo libraries from CERNLIB because I knew their status was likely to become an FAQ. All of the applications listed above are far more difficult to package than the non-free Monte Carlo libraries. If you do package these, however, let me know and I'll mention it here.

4.4. Isn't the license of cfortran.h non-free?

The license of cfortran.h given here is certainly non-free. However, I contacted the author, Burkhard Steinmacher-Burow (steinmac at us.ibm.com), and asked whether cfortran.h could be re-licensed so that it could be distributed by Debian. He agreed in a private email to re-license it under the Library GPL, although this re-licensing has not yet shown up on the cfortran web page. Unfortunately he is very busy, and a new upstream version of cfortran.h will not be released for a long time, if ever.

4.5. I found a security flaw in CERNLIB. Can I send you encrypted email?

(For the record, this question isn't frequently asked.)

You can contact me securely by sending email to <kmccarty@debian.org> PGP-encrypted to PGP public key ID 4F83C751. The key fingerprint is as follows:

5AFC 1914 1A2F C632 2A85 AE9B 7D8C 4022 4F83 C751

This page last modified May 19, 2008.