Last modified 6 years ago Last modified on 02/01/2013 01:03:16 AM

Building CORAL

CORAL-based applications can be built using releases pre-installed in the CERN afs space. These releases are world-wide readible, no special account is needed. Given that LSST will likely require more independence and possibly some LSST-specific customizations, we will need to make our standalone build(s). I tried both. Quick summary:

  • I built and run my small test application against CERN afs version. It was simple, I got it to work quickly.
  • I made a complete build of CORAL on a slac machine, with no dependencies on CERN afs. It was much harder (close to a week of chasing various issues). I finally go it to work on Scientific Linux 3 gcc 3.2.3 after making several patches.
  • I did not manage to build CORAL on Redhat Enterprise 4 gcc 3.4 running in 64 bit mode. It fails with "skipping incompatible". Reason: prebuild SEAL libraries are in 32 bit mode, but objects produced by my build are in 64 bit even though I set architecture to 32 bit. CERN folks claim they have 64 bit version of all libraries, but these libraries failed to download ("could not download the file : uuid_1.38__LCG_slc4_amd64_gcc34.tar.gz" if I try downloading CORAL 1.7.0 or "could not download the file :" if I try downloading latest CORAL 1.8.0).
  • I did not manage to build SEAL. It is misconfigured as far as I can tell ("can't find Makefile"). So I am forced to use libraries and binaries transfered during installation. That would be ok since we don't need to mess with it anyway, but I'd like to rebuild it because of the 32 bit / 64 bit mode problems mentioned above.

More details below.

CERN-based build

Related instructions: Few comments:

  • do NOT use -pedantic-errors flag, or you will get an error: "ISO C++ does not support 'long long'"
  • link against -llcg_RelationalAccess -llcg_CoralBase, not -llcg_coral_RelationalAccess -llcg_coral_CoralBase as the webpage suggests.

The command I used to (successfully) build my simple test program:

g++ -o run_cern coralTest.cpp -D_GNU_SOURCE -DGNU_SOURCE -fPIC -pthread -pipe -ansi 
    -llcg_RelationalAccess -llcg_CoralBase 
    -llcg_SealKernel -llcg_PluginManager 
    -llcg_SealBase -luuid -lpcre -lnsl -lcrypt -ldl -Wl,-E

If you also include -Wl,-R/afs/ options for the shared library and modules directories, the LD_LIBRARY_PATH environment variable setting below should not be needed.

I build it on RHEL3 with gcc 3.2.3

To run the program, I had to set env vars:

setenv LD_LIBRARY_PATH /afs/


A standalone build

Instructions how to make a completely independent build (no dependency on CERN afs) are at:

Allegedly supported platforms:

  • slc3_ia32_gcc323
  • slc4_ia32_gcc34
  • slc4_amd64_gcc34

I managed to build only slc3_ia32_gcc323, I tried all 3.

Don't look inside to see what is supported, I made that mistake. CERN folks say only the 3 platforms listed above are supported at the moment. Also, be aware that there are issues with newer compilers, so do stick with suggested versions of gcc.

Also, be aware that the installation script hardcodes provided prefix in many places, so you can't simply install it on one machine and then scp installed directories to a different machine (unless paths on both machines are exactly the same). I needed to install coral on a machine inside Internet Free Zone. Solution suggested by CERN is to use http proxy, but at slac we don't allow http proxy servers so that does not work. I ended up making the paths look the same on the machine where I run installation script and the destination machine. It worked, but later I learned that I can't build coral on my final destination machine anyway...

Commands I ended up running to build slc3_gcc323 version (on

cd /usr/work/becla/
mkdir lcg
cd lcg
chmod 755

# this command downloads ~ 1 GB of data (it took ~13 minutes)
./ --project=CORAL_1_7_0 --arch=slc3_ia32_gcc323 
--prefix=/usr/work/becla/lcg download >& lcg-installation-manager.log

setenv PATH ${PATH}:/usr/work/becla/lcg/app/spi/scram
setenv SCRAM_ARCH slc3_ia32_gcc323
scram list ## should show two links

# I found I had to create an extra link, or I get error:
# Parse Error in /usr/work/becla/lcg/app/releases/CORAL/CORAL_1_7_0/src/CoralBase/BuildFile, line 7
# Unable to find SubSystem [...] include/Framework/SealKernel/BuildFile
# I think it is a bug in installation script, anyway, this "fixes" it:
cd /usr/work/becla/lcg/app/releases/SEAL
ln -s SEAL_1_9_2 SEAL_1_9_1 

# I found there are some linking errors which can be fixed by editing several "BuildFile" files 
# and removing coral_, for example lcg_coral_LFCLookupService --> lcg_LFCLookupService. So:
cd app/releases/CORAL/CORAL_1_7_0/src/
find . | grep Build | xargs grep _coral_ | awk -F: '{ print $1}'
# then edit the files...

# I also found that OracleAccess fails to build, error:
# OracleAccess/src/OracleErrorHandler.h:5:22: oratypes.h
# This is probably due to missing include, I simply got rid of OracleAccess package
# since we don't need it anyway
rm -rf OracleAccess

# finally I built CORAL. It took 12 minutes
cd app/releases/CORAL/CORAL_1_7_0/src/
scram build >& build.log
# "CORAL built!" at the end means success...

Then to build and run my test application:

g++ -o run coralTest.cpp -D_GNU_SOURCE -DGNU_SOURCE -fPIC -pthread -pipe -ansi 
  -llcg_RelationalAccess -llcg_CoralBase 
  -llcg_SealKernel -llcg_PluginManager -llcg_SealBase -luuid -lpcre -lnsl -lcrypt -ldl -Wl,-E



To access CORAL from lsst-dev01 (behind firewall, running rhel4 in 64 bit mode) I ended up redoing the build on yakut02 (sl3) and putting everything on nfs, then accessing libraries and binaries through nfs. It worked. The only caveat: On lsst-dev01 I have mysql 5.0.37, and the mysql libraries supplied with CORAL are for 5.0.18 and they seem to be incompatible. I ended up using /usr/lib instead of /usr/work/becla/lcg/external/mysql/5.0.18/slc3_ia32_gcc323/lib in the LD_LIBRARY_PATH.

This had a nasty side effect: on yakut, where mysql in not in /usr/lib, I then started to get

CORAL Exception : Relational domain "mysql" could not be found ( CORAL : "IRelationalService::domain" 
from "CORAL/Services/RelationalService" )

changing the LD_LIBRARY_PATH back to the old value was not sufficient, I found I also had to clear a cache file: <baseDir>/app/releases/CORAL/CORAL_1_7_0/slc3_ia32_gcc323/lib/modules/.cache

I also managed to run my application built with CORAL on laptop (Fedora Core 5). To do that, I had to build CORAL on yakut02 (sl3 gcc323), and access build libraries and binaries through afs.