Add plain libraries to LD_LIBRARY_PATH in run

So far gaudi_add_library did not add anything to the LD_LIBRARY_PATH in the runtime environment generated in <project>env.sh. This was probably not spotted until now because usually subdirectories also have plugin libraries, and then gaudi_add_module would add to the path.

added bug fix build system labels

assigned to @clemenci

This is actually done on purpose as libraries are located via RPATH (in the build environment), while modules require to be added to LD_LIBRARY_PATH as they need to be found via dlopen.

I have an idea of a case where the current behaviour might not work. Why do you say this is a problem?

Okay, this makes sense.

I saw this when trying to run an LHCb Online program. The issue is that different programs are started with the same generic executable that uses dlopen to call the specific functions:

genRunner.exe libSmiController.so smi_controller [options]

I guess a solution for this case would be to call lhcb_env in the relevant CMakeLists.txt to extend LD_LIBRARY_PATH?

PS Maybe we should also add your explanation as a comment here.

In this specific case, we have a gaudi_add_library for something that should have used gaudi_add_module (which implies the .so is loadable with dlopen).

OTOH, the there's also an executable called smi_controller in that subdir and from a brief look the calls

genRunner.exe libSmiController.so smi_controller [options]

and

smi_controller [options]

are equivalent... do we need to have both of we can stick to just one way of invoking the smi_controller?

I would have to defer this question to @frankm

I must admit I fail to understand the problem... These are all non-Gaudi processes and yes, they are bootstrapped with dlopen(), which loads the implementing library and call a certain function.

The "problem" is that dlopen relies on LD_LIBRARY_PATH and that is not explicitly populated but it happens to be populated "by accident". In very specific circumstances LD_LIBRARY_PATH actually doesn't contain e.g. libSmiController.so and thus dlopen fails.

Marco's question is valid, thought. Is there a reason to prefer genRunner.exe vs dedicated executables?

If they are supposed to be loaded via dlopen, then one should use gaudi_add_module and not gaudi_add_library. In the specific case libSmiController.so is not only used via dlopen, but also linked to the the executable smi_contoller which is not a supported use case in Gaudi (i.e. in Gaudi CMake helpers).

1. I do not like individual executables, because then for every tiny test a new executable floods the command-space.
2. Secondly there are 2 library invoking executables "genRunner" and "gentest". The difference is that one catches all all output to stdout/stderr, reformats it and ejects it a json to a fifo, so that the output is understood by kafka for logging. The latter is used for command line debugging and dumps directly to stdout/stderr.

But: is the problem not very academic here: This mechanism is only used for online tasks. These are only (re-)started after a "make install". The shared library should then always be present -- no? In fact when I create the setup scripts I think I explicitly remove all dependencies to the the build areas.

Is there a use case where this will really fail?

For Gaudi tasks there is only the "genPython", which does nothing else than overloading the C runtime to capture stdout/stderr and then invoking the python interpreter with whatever arguments come. If this exe runs into some trouble then we have a problem which must be sorted out.

Above is of course only true if not some weird-do start a program with: genRunner.exe `which python` main ....args....

Fine with me, so we should use gaudi_add_module and drop the smi_controller executable that you just said should not exist.

Where is really the difference between a "module" and a "library" ? Is there some plan to shrink symbol visibility ?

My use case that triggered this is precisely when I am running within the environment generated with the <project>env.sh script (no InstallArea). I understand this is not the normal way to start tasks in production but it is quite convenient for development.

from CMake doc

MODULE libraries are plugins that are not linked into other targets but may be loaded dynamically at runtime using dlopen-like functionality

For the moment we do not tune symbol visibility, but it is in the pipeline (may be in a year or so... if ever).

mentioned in commit lhcb/Online@dbf5b9c6

closed