FairRootGroup / FairRoot

C++ simulation, reconstruction and analysis framework for particle physics experiments
http://fairroot.gsi.de
Other
59 stars 96 forks source link

CMake warnings on mcconfigurator #1578

Open YanzhaoW opened 4 months ago

YanzhaoW commented 4 months ago

Describe the bug When configuring FairRoot CMake in a conda environment, following warning is given by CMake:

CMake Warning at fairroot/mcconfigurator/CMakeLists.txt:17 (add_library):
  Cannot generate a safe runtime search path for target MCConfigurator
  because files in some directories may conflict with libraries in implicit
  directories:

    runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /u/yanwang/miniconda3/lib
    runtime library [libexpat.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
      /u/yanwang/miniconda3/lib

  Some of these libraries may not be found correctly.

System information (please complete the following information):

dennisklein commented 4 months ago

So, CMake finds libz and libexpat in /usr/lib/x86_64-linux-gnu and makes a sanity check with your run-time ld config which provides those libs in /u/yanwang/miniconda3/lib - and warns you about it. To fix this, you could try pointing CMake to your miniconda3 libs via -DZLIB_ROOT=/u/yanwang/miniconda3 -DEXPAT_ROOT=/u/yanwang/miniconda3 or alternatively -DCMAKE_PREFIX_PATH=/u/yanwang/miniconda3. Or, if you want to use the system libs, unload/modify your conda environment.

YanzhaoW commented 4 months ago

I see. So if I do nothing, CMake would still use the system libs for libz and libexpat?

dennisklein commented 4 months ago

The question is what is your intention with putting those miniconda libs in your run-time config but different ones in your build time config. CMake is just warning you after all. If you do this intentionally, then you have your reasons, no?

YanzhaoW commented 4 months ago

Sorry, I don't quite understand it.

By "run-time config", I guess you meant the configuration set with LD_LIBRARY_PATH and PATH env variables I use to build FairRoot. These two env variables are appended with the conda path automatically when I enable the environment.

With "build time config", do you mean the LD_LIBRARY_PATH and PATH config when I built the FairSoft?

fuhlig1 commented 4 months ago

The question probably is why do you need the miniconda environment when installing FairRoot.

dennisklein commented 4 months ago
   LD_LIBRARY_PATH
         A list of directories in which to search for ELF libraries
         at execution time.  The items in the list are separated by
         either colons or semicolons, and there is no support for
         escaping either separator.  A zero-length directory name
         indicates the current working directory.
         (...)

https://man7.org/linux/man-pages/man8/ld.so.8.html subsection Environment Variables

With "build time config", do you mean the LD_LIBRARY_PATH and PATH config when I built the FairSoft?

No, $LD_LIBRARY_PATH is only used at run-time - it is a library search path for the dynamic linker. $PATH is again a completely different search path which is typically used by your shell to find commands which you specify without any file path.


YanzhaoW commented 4 months ago

Thanks for your detailed explanation. It clears up many things for me.

I checked again with my conda environment. It actually doesn't set $LD_LIBABRAY_PATH at all. The only changed relevant env variable I could see is $PATH.

So I open the CMakeCache.txt to see how my miniconda3/lib sneaks into the CMake configuration. Then I found out that it is yaml-cpp package and CMake somehow find the one that I installed from the Conda environment. Knowing this, I went to CMake website to check how CMake finds required packages:

Search the standard system environment variables. This can be skipped if NO_SYSTEM_ENVIRONMENT_PATH is passed or by setting the CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH to FALSE. Path entries ending in /bin or /sbin are automatically converted to their parent directories: PATH

So CMake does use $PATH environment during the configuration to find yaml-cpp package. The yaml-cpp installed in Conda is naturally linked to zlib in miniconda3/lib while the same target MCConfigurator is also linked to another zlib either through root or geant4vmc.

Therefore, simply specifying zlib path with -DZLIB_ROOT=/u/yanwang/miniconda3 -DEXPAT_ROOT=/u/yanwang/miniconda3 for CMake doesn't work and I got more warnings. The solution should be explicitly set the yaml package path for CMake instead:

cmake -Dyaml-cpp_ROOT=/usr/lib/x86_64-linux-gnu/cmake/yaml-cpp ..

But should we put yaml-cpp into FairSoft such that CMake could find it using ${CMAKE_PREFIX_PATH}?

dennisklein commented 4 months ago

I don't follow in all details. Can you share your CMakeCache.txt or at least the entries for expat and zlib? (when the original warning happens without specifying additional hints as discussed here)

fuhlig1 commented 4 months ago

@YanzhaoW,

I think your findings are correct. Geant4VMC and Geant4 libraries link against libz and libexpat which in your case where found in the system. When compiling FairRoot geant4vmc and yaml-cpp are required as dependencies for MCConfigurator which come with conflicting requirements for libz and and libexpat.

Did you use your miniconda environment also when compiling FairSoft?

YanzhaoW commented 4 months ago

Hi, @dennisklein

Here is the CMakeCache.txt generated in conda environment: CMakeCache.txt

YanzhaoW commented 4 months ago

Hi, @fuhlig1

I don't think I did. But it would be nice if FairSoft also contains yaml-cpp by itself and then everything would be compatible with each other. There will be always some problems if we just let CMake find yaml-cpp in whatever way.