Athena Developer Guide

Athena Chapter 18 Framework packages, interfaces and libraries Version/Issue: 2.0.0
the component libraries, export all the symbols and are needed during the linking phase in the
application building. These libraries can be linked to the application "statically" or "dynamically",
requiring a different file format. In the first case the code is added physically to the executable file. In
this case, changes in these libraries require the application to be re-linked, even if these changes do not
affect the interfaces. In the second case, the linker only adds into the executable minimal information
required for loading the library and resolving the symbols at run time. Locating and loading the proper
shareable library at run time is done exclusively using the LD_LIBRARY_PATH for Linux and PATH
for Windows. The convention in Gaudi is that linker libraries have the same name as the package,
suffixed by "Lib" (and prefixed by "lib" on Linux, e.g. libMyComponentsLib.so).
18.4.3 Library strategy and dual purpose libraries
Because component libraries are not designed to be linked against, it is important to separate the
functionalities of these libraries from linker libraries. For example, consider the case of a DataProvider
service that provides DataObjects for clients. It is important that the declarations and definitions of the
DataObjects be handled by a different shared library than that handling the service itself. This implies
the presence of two different packages - one for the component library, the other for the DataObjects.
Clients should only depend on the second of these packages. Obviously the package handling the
component library will in general also depend on the second package.
It is possible to have dual purpose libraries - ones which are simultaneously component and linker
libraries. In general such libraries will contain DataObjects and ContainedObjects, together with their
converters and associated factories. It is recommended that such dual purpose libraries be separated
from single purpose component or linker libraries. Consider the case where several Algorithms share
the use of several DataObjects (e.g. where one Algorithm creates them and registers them with the
transient event store, and another Algorithm locates them), and also share the use of some helper
classes in order to decode and manipulate the contents of the DataObjects. It is recommended that three
different packages be used for this - one pure component package for the Algorithms, one dual-purpose
for the DataObjects, and one pure linker package for the helper classes.
18.4.4 Building and linking with the libraries
Gaudi libraries and applications are built using CMT, but may be used also by experiments using other
configuration management tools, such as ATLAS SRT.
18.4.4.1 Building and linking to the Gaudi libraries with CMT
page 166
Gaudi libraries and applications are built using CMT taking advantage of the CMT macros defined in
the GaudiPolicy package. As an example, the CMT requirements file of the GaudiTools
package is shown in Listing 18.7. The linker and component libraries are defined on lines 23 and 26
respectively - the linker library is defined first because it must be built ahead of the component library.
Lines 28 and 34 set up the generic linker options and flags for the linker library, which are suffixed by
the package specific flags set up by line 35. Line 31 tells CMT to generate the symbols needed for the