In the context of generating python bindings using boost::python to access routines that make use of ROOT C++ libraries, it was spotted that the behaviour of NumPy was changing depending on the order of the imports. To reproduce it one can simply write the following in a C++ file (namely “module.cpp”):
In the latter the warning will appear only in the first python call but as you can see in the third call the behaviour changes as soon as “module” is imported. This seems to be caused by the library ROOTVecOps (removing it from the list makes the warning disappear). Looking into the CMakeLists.txt file in the source repository
the library is enabling always -ffast-math, which in the case of being true, it is extremely dangerous since it compromises any code that is linked against it with an unexpected behaviour. So far the solution in my case is to explicitly avoid that library implementing a workaround, although it becomes relatively difficult because it is provided by default in the environment variable ROOT_LIBRARIES when using find_package in CMake. In addition, the problem propagates to any ROOT library that depends on ROOTVecOps, like ROOTDataFrame.
Thanks a lot for promptly digging into this @eguiraud. Indeed I hadn’t realized that the PRIVATE keyword is being used, and that should not propagate the links as part of the ROOTVecOps library interface. Given that the problem seems to indirectly come from libvdt, I am wondering what could be the solution for this. Could be possible to specify also PRIVATE for vdt if it comes from the system? My concern is that this behaviour is present in the LCG releases, and from my perspective it should be consistent independently of where the vdt library comes from (although there might be some argument for this). From what I understood about -ffast-math, if not handled carefully its effects can be widely propagated, and I wonder how many people are affected by this who haven’t noticed yet.