Core Issues 25 July 2001

Previous status report; 

pdrApp v5r1 is released. But: still a problem starting the app on linux.

A little tutorial on Gaudi applications

A Gaudi executable is very small, only 33 kB on Windows without the GUI, 189 kB with. Like ROOT, it loads the requested code dynamically.

How does Gaudi load DLL's? [shorthand for shareables, .dll for Windows, .so for unix]. Consider a fragment from the  jobOptions file for pdrApp:

ApplicationMgr.DLLs = {
"GaudiAlg",
"GlastSvc",
"FluxSvc",
"GismoGenerator",
"RootHistCnv",
"ntupleWriterSvc"};

The application manager looks for DLL's with these names, and loads them dynamically. The output normally will be:

DllClassManager INFO Loaded 3 factories from module GaudiAlg
DllClassManager INFO Loaded 7 factories from module GlastSvc
DllClassManager INFO Loaded 1 factories from module FluxSvc
DllClassManager INFO Loaded 2 factories from module GismoGenerator
DllClassManager INFO Loaded 9 factories from module RootHistCnv
DllClassManager INFO Loaded 2 factories from module ntupleWriterSvc

This shows that Gaudi has loaded them, and executed the entry point function

extern "C" FactoryTable::EntryList* getFactoryEntries()

that each has declared, and then installed the corresponding "factories" in each. [See Riccardo's discussion on creational patterns, including the Factory.] For example, ntupleWriterSvc has two, a Service "ntupleWriterSvc", and an Algorithm, "writeTupleAlg". These are declared in the file ntupleWriterSvc_load.cxx.

Now how did it find the DLLs? There are two mechanisms, used in order:

• Use environment variable <package>Shr, for example ntupleWriterSvcShr, which has a value corresponding to the full path to the binary DLL. (Needing only a ".so" or ".dll" to be appended.)
• If the above fails, then attempt to load (using the system function dlopen  (unix) or LoadLibrary (Windows) with the DLL name alone. This works if either the file is in the default directory, or in a directory in the environment variable LD_LIBRARY_PATH (unix) or PATH (Windows).

A package can choose one or the other mechanism using CMT patterns that have been defined in the GaudiPolicy requirements file. The two statements that may appear in a requirements files are, in order:

• apply_pattern packageShr
• apply_pattern ld_library_path

The first translates into a set statement, the second to a macro_append. Either affects the execution environment via a script setup.sh or setup.bat. That is, when executed, by source setup.sh or running setup.bat, the appropriate environment variables will be set. Clearly the first mechanism is preferred, and most packages use it, because it is safer: the full path generated by CMT is a guarantee that the proper version is loaded.

A footnote: the Gaudi kernel has two parts: a lib that is linked with the main, and a DLL that the operating system must find. It then loads the rest of the Gaudi system, in the package GaudiSys, using this mechanism.

What is wrong?

Three of our packages, FluxSvc and GismoGenerator, and GaudiSvc itself, apparently fail to load on linux unless they are in LD_LIBRARY_PATH. A lot of effort has been spent tracking this down, it is still not understood. We suspect that this is a consequence of our attempt to use some internals of the random number service to coordinate legacy CLHEP random number generators.

A note added about use ot LD_LIBRARY_PATH, from Pat Nolan:

I'm a bit concerned about the use of the LD_LIBRARY_PATH variable. I don't like to use this method, and I'm not alone in this opinion. Basically you end up polluting a global namespace with application-specific stuff. I have seen some examples that are really gross.

If you read the man pages for "ld" on Linux and Solaris, you will see that it is possible to link an executable with a hard-wired library path built in. I think this is suitable for the problem you discussed. On Linux this requires the use of the -rpath option. On Solaris it's -R.

 

T. Burnett