• View
• Edit
• History
• Print

LogBook

Support libraries

SigC++

• In /usr/lib/pkgconfig ln -s /usr/lib64/pkgconfig/sigc++.1.2.pc
• In /usr/include/ ln -s /usr/lib64/sigc++_1.2/include/sigconfig.h

Pythia6

• Rebuilt Pythia6 with /usr/local/cern/pythia6/build6/build_phythia6.sh, changed g77 to gfortran everywhere

Neugen3

• In neugen3, change Make.include as follows before rebuilding

	CERNLIB =  /usr/local/cern/2005/lib 
	FORT     := gfortran 
	FORTOPTS := $(FFLAGS) -fno-second-underscore -fPIC -g -c -DLINUX $(NEUGENINCS) -I$(LUNDINCS) 

• In neugen 3, change

ifeq ($(MINOS_ARCH),linux)

  # make compile options compatible with standard MINOS options
  # (critical is lack of second underscore)
  # (for linking with NeugenInterface .so library one needs -fPIC)

FORTOPTS := $(FORTOPTS) -DLINUX \

              -fno-second-underscore -ffortran-bounds-check -fPIC -Wall

endif

to

ifeq ($(MINOS_ARCH),linux)

  # make compile options compatible with standard MINOS options
  # (critical is lack of second underscore)
  # (for linking with NeugenInterface .so library one needs -fPIC)

FORTOPTS := $(FORTOPTS) -DLINUX \

              -fno-second-underscore -fPIC -Wall

endif

ROOT

h2root appears broken (gives segmentation faults) on the 64 bit machine. This ROOT Talk thread indicates the solution is upgrading to a newer version of ROOT (>5.23/02). However, using ROOT 5.23.04 still results in a segmentation violation, albeit later in the running, on the 64bit machine at Indiana.

Other

• In /usr/lib, rename each of the following files to something else and ln -s ../lib64/[file]
  • libGL.so
  • libdl.a
  • libdl.so
  • libpthread.so
  • libpthread.a
  • libsigc-1.2.a
  • libsigc-1.2.so

MINOS Code

Core Issues

Compiler Options

• Added -fPIC to SRT_MINOS/SoftRelTools/arch_spec_root.mk
• Made a new version of arch_spec_f77.mk in $SRT_PUBLIC_CONTEXT/SRT_MINOS/SoftRelTools/ that uses gfortran and lgfortran rather than g77 or f77.

Changed

ifndef SRT_USE_F2C

else

endif

into

ifdef SRT_USE_GFORTRAN

else

endif

• Note, it is most effective to run gmake in the directory in one's private release containing all of these packages rather than compiling each package individually. Otherwise, one gets errors about not having -fPIC. The error in TriD remains even when this is done, for reasons unknown.

Backend Libraries

Package specific issues

CandUid

• Pointers cast as UInt_t changed to ULong_t in CandUid.cxx

CDFMonitoringFwk

• In CDFMonitoringFwk/ConsumerExport.cc if ((Long_t)signal(SIGPIPE,pipeBroken) == -1) //Changed (int) to (Long_t) to ensure compatibility with 64-bit architecture.

Midad

• In Midad/Gui/GuiMenu.cxx, changed several (int) to (Long_t). Note that the first two instances of this were reconginzed as "evil" by a previous commenter.

NtupleUtils

• In NtupleUtils/NuMatrixFitter.cxx, changed (int) to (Long_t) in two instances

TriD

• In TriD/TridModel.cxx, changed (int) to (Long_t) in one instance.
• When I compile TriD in my private test release (using my Contrib/64bit version) compilation fails with and error saying "recompile with -fPIC"

LegacyCand

• In LegacyCand, moved the #include command to include file *Handle.h from the .cxx file to the .h file for the following
  • CandClusterSR.cxx
  • CandClusterSRList.cxx
  • CandEventSR.cxx
  • CandEventSRList.cxx
  • CandShowerSR.cxx
  • CandShowerSRList.cxx
  • CandSliceSRList.cxx
  • CandSliceSR.cxx
  • CandStripSR.cxx
  • CandStripSRList.cxx
• Also removed "LegacyCand/" from the paths of #include statements. This was done for the statements in files that are in the LegacyCand directory.

Minos MC

• We do not need MinosMC, so do not worry about the compilation error. Removed the pacakage with rmpkg MinosMC

PmtDrift

• Do not worry about errors in PmtDrift package for now

Measures specific to Indiana University

• Changed /home/minos/setup.csh to /home/minos/setup-new.csh; in setup-new.csh and srt.csh, changed minos to minos-new
• In /home/minos/setupnew set LUNDLIBS to /usr/local/cern/pythia6/v6_420/lib and set PYTHIA /usr/local/cern/pythia6/v6_420/
• setenv NEUGEN3PATH /usr/local/minos-new/neugen3/
• run "make update" in /usr/local/minos-new/labyrinth/

32-bit compatibility libraries

Although the aim is to migrate to 64 bit a possible interim step is to build and run in 32-bit compatiblity. Art found this link https://twiki.cern.ch/twiki/bin/view/Atlas/RPMcompatSLC4#Build_in_32_bit_on_SLC4_64_bit_s

Generating Standard Ntuples

Currently, at Indiana, we run the command loon -bq -r 1000 ../asciidb/set_tsql_override.C reco_near_spill_data_base_dogwood1.C /data/en/3b/users/lacorwin/RashidData/Near/N00010645_0000.mdaq.root in the $SRT_PRIVATE_CONTEXT/Production/Dogwood directory. This runs without error on our 32-bit machine. On the 64-bit machine, the output is identical to the 32-bit machine until

GeoGeometry build for validity {  Near|  Data|2006-08-11 07:20:05.387043276Z}.
Abort (core dumped)

*** glibc detected *** loon: double free or corruption (fasttop): 0x000000000a11
89c0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3fa6271684]
/lib64/libc.so.6(cfree+0x8c)[0x3fa6274ccc]
/usr/local/cern/root/5.23.04/lib/libCore.so(_ZN8TStorage13ObjectDeallocEPv+0x79)
[0x2afb9c0723bb]

This is followed by a long list of other errors.

Following advice from the Ubuntu Forums, I used setenv MALLOC_CHECK_ 0 to eliminate the errors following the abort. However, the process still crashes with the following at the end of the output.

GeoGeometry build for validity {  Near|  Data|2006-08-11 07:20:05.387043276Z}.
Segmentation fault (core dumped)

The crash has so far been traced to the StripSRListModule, to the command CandStripList::MakeCandidate(). In MakeCandidate(), the crash occurs in RunAlg which is a function from AlgHandle. Specifically, the crash occurs in $SRT_PRIVATE_CONTEXT/Algorithm/AlgHandle.cxx at the line fAlgBase->RunAlg((AlgConfig &) *fAlgConfigRef.GetObject(), ch, cx);