Physics Hacker

If you run a python script that imports GaudiPython (or any LHCb modules for that matter) inside gdb on any lxplus node, you will run into an error like this:

[lxplus223] ~ > gdb python
GNU gdb Red Hat Linux (6.3.0.0-1.162.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"
   ...Using host libthread_db library "/lib64/tls/libthread_db.so.1".

(gdb) set args test.py
(gdb) run
Starting program:
   /afs/cern.ch/sw/lcg/external/Python/2.5.4p2/slc4_amd64_gcc34/bin/python test.py
[Thread debugging using libthread_db enabled]
[New Thread 182894205120 (LWP 11117)]
Traceback (most recent call last):
  File "test.py", line 1, in
    import GaudiPython
ImportError: No module named GaudiPython

Program exited with code 01.
(gdb)

This is due to our group-login script (including the “rc” one)
using LbLogin and that reshuffles the paths. When gdb starts
the process to be debugged and if a SHELL variable is present,
it is started with “$SHELL -c”.
When it is perfectly legal for bash (it only starts a new shell),
with (t)csh it starts a new *login* shell corrupting the already
setup paths (PATH, LD_LIBRARY_PATH, PYTHONPATH etc).

So in order to solve this you have to unset SHELL inside
gdb (maybe best to place that in .gdbinit):

unset environment SHELL

Since today Google Streetview is available for Switzerland. It covers quite a few streets and among them is the road to CERN.

Here you can see the main entrance:

And here you can see the ATLAS building

… the CERN Globe:

LHCb Experiment:

So after a long time I finally figured out today how to set alternative
compile options in CMT when using the LHCb framework.

First there are some additonal tags besides the well known tags

for production and debugging code

slc4_amd64_gcc34
slc4_amd64_gcc34_db

one is for code coverage the other for performance tests

tag slc3_ia32_gcc344_cov
tag slc3_ia32_gcc344_pro

Most important is where all this stuff is set,

it’s in

 GaudiPolicy/cmt/requirements

Problem with the XXX_cov and XXX_pro is that there are no
supported prebuild binaries by CERN. So it’s all or nothing either
you build everything on your own or you are stuck. You can work
around that with a little hack:
getpack the GaudiPolicy package to your local cmtuser directory
and just add your additional flags to a supported tag.

If you just want to alter the cppflags for one package you would
just add something like this to the package’s requirements file:

macro_append cppflags " -g "

or

macro_append cppflags "" Linux " -g " Windows " -foo -bar"

Where Linux and Windows would act as a switch for different
compilation setups.and the quoted strings would be the appended
options. Note the first empty qoutes in the second example it’s just
the empty standard case.

Update:

As Stefan Roiser pointed out to me over at the cmt mailing list,
one possibility would be to produce your own requirements file

/my/dir/to/cmt/requirements

put your macro_append etc into there and set an enviornment variable

CMTUSERCONTEXT=/my/dir/to/cmt

Then your requirements file should be processed last, thus changing
appending your compiler flags etc as a last step of the configuration before
executing the make.

Also on the cmt mailing list Grigory Rybkin explained, that if you ever wonder
why your cppflags or any other macro behave weird you could check with

cmt show macro cppflags

Example output for package Moore on a Linux machine:

# Package CMT v1r20p20070208 defines macro cppflags as '-pipe -ansi -pedantic -W -Wall -Wwrite-strings
 -Wpointer-arith -Woverloaded-virtual ' for tag 'Linux'
# Package GaudiPolicy v8r5 defines macro cppflags as ' -fmessage-length=0 -Df2cFortran -fPIC -shared
 -D_GNU_SOURCE -Dlinux -Dunix -pipe -ansi -Wall -Wextra -pthread ' for default tag
# Package GaudiConf v10r13 appends to macro cppflags : ' -DAPPNAME=\"${package}\"
 -DAPPVERS=\"${version}\" ' for default tag
# Package RichKernel v7r17 appends to macro cppflags : ' -DRICHDEBUG ' for tag 'Linux&debug'
# Package LHCbKernel v9r2 remove from macro cppflags : '-DGOD_NOALLOC' for default tag
#
# Selection :
cppflags=' -fmessage-length=0 -Df2cFortran -fPIC -shared -D_GNU_SOURCE -Dlinux -Dunix -pipe -ansi
 -Wall -Wextra -pthread  -DAPPNAME=\"${package}\" -DAPPVERS=\"${version}\" -DRICHDEBUG '

And then use the “-e” option of make via brodcast, like:

cppflags=MYFLAGS cmt br make -e

it orders make to give environment precedence over variables from makefiles.