Installation of ROOT to a user-defined prefix results in broken libraries for external packages (R, cfitsio)

ROOT
1

ROOT Version: 6.20.04
Platform: openSUSE 15.1 / x86_64
Compiler: gcc 7.5.0

Dear ROOT Users & Developers,

Further investigation of the issues I reported with regards to building ROOT with R statistics (ROOTR),
see Issues when building ROOT with R statistics (ROOTR)
did show that the steps I took to successfully build against R lead to ROOTR working from the bin directory of the build tree, while installing ROOT to a user-defined prefix and then executing it from the installation directory resulted in ROOTR failing.

This behavior was confirmed by @wile_e_coyote who also pointed out that this finding was caused by the libraries

libRInterface.so
libRMVA.so
libRtools.so

being broken by (or at least after) installation to a user-defined prefix. Following his approach, I can now confirm that this not only happens on my system for the libraries named above, but it also happens for

libFITSIO.so

All libraries that are broken by installation of ROOT share one common feature: They relate to external packages (R, cfitsio) that I have built and installed (to user-defined prefixes) from source. As these are the only two packages this situation applies to, I cannot tell whether this is a systematic “feature” (bug?) of installing ROOT, but it might hint at an approach for solving this issue.

For the time being, I ended up with a brute-force fix that probably should not be taken: Replacing the named libraries in the installation directory by the ones from the build tree does result in an apparently working installation… :thinking:

If I had any decent knowledge of CMake and its install procedure, I would try propose a clean fix, but unfortunately I am lacking the necessary knowledge. I would be happy to hear someone is able to come up with a systematic fix.

Thank you as always, and stay safe,

Wolf

2

What library is missing for libFITSIO.so?

3 
ldd ${ROOTSYS}/lib/libFITSIO.so

reports:

libcfitsio.so.8 => not found
4

Where does it come from for the original library (before “install”)?

5 
ldd <builddir>/lib/libFITSIO.so

reports:

libcfitsio.so.8 => /usr/local/cfitsio-3.47/lib64/libcfitsio.so.8
6

So, try:
export LD_LIBRARY_PATH="/usr/local/cfitsio-3.47/lib64:${LD_LIBRARY_PATH}"

7

I agree with you that this should fix the issue.

However, as stated in my initial post, I opted for the “dirty” solution of replacing libFITSIO.so in the ROOT install directory by the “same” (not really…) file of my ROOT build tree - works…

8

Maybe you could try a really brutal fix (rebuild ROOT with): cmake -Drpath=ON ...

Then execute “make install”, rename the original “<builddir>” (so that the newly installed libraries will NOT find the originals) and try “ldd” on all newly installed libraries.

9

I did not consider that flag – are you implying that the behavior I reported as a “issue” is indeed intended? If so, shame on me…

10

I am a bit surprised that the install is “stripping” some information from the library (as your symptom seems to indicate) but nevermind …

Indeed using -rpath=ON is clearly what you want/need in this case as it explicitly says please record the location of the libraries cmake discovered and use those (almost) no matter what.

1 Like
11

@pcanal and @Wile_E_Coyote: Thank you for pointing me to the -Drpath=ON flag.

I followed your advice and rebuilt ROOT yet again using this flag. I can confirm that by enabling the flag, installation to a user-defined prefix does no longer “break” libraries originating from user-built and -installed external packages (i.e. R and cfitsio in my case). Now, ROOT does indeed work from its installation directory and does automatically locate and load all libraries as expected, i.e. also those required for R and cfitsio in my case.

Thank you very much for your help, and please accept my apologies for taking some time to follow your suggestions and reporting back to the forum.

Stay safe,

Wolf

12

@pcanal: While I am very happy that the suggested solution did fix the issue I reported, it made me wonder about the -Drpath=ON flag. I went through all of the flags and options listed before my initial build and did not have the impression setting it would be necessary, although it apparently is. In an attempt to learn something, my question is the following:

What is the reason for this flag not to be set as ON by default for all ROOT builds, and what are the (unwanted) potential implications of setting it (as I assume it would always be ON by default if there was nothing to be worried about)?

I would appreciate if an expert would be willing to share some insight here - who knows when it will come in handy…

Thank you,

Wolf

13

It is very common to want to build and install ROOT in a set of directories and then tar the result up and install it on a different machine … in a different directory … in that case the rpath information is in the way.

14

Good point, thank you. I did not think of “distributed” installations as this is not relevant to my system-specific installation and use. For those cases, however, it might still seem worthwhile to investigate the initially reported issue of the install “stripping” some information from some of the libraries…

15

As @pcanal says, consider -Drpath=ON as a really brutal fix, needed now.
Whatever you build against this ROOT version will have all shared libraries’ paths “encoded” by hard.
As soon as the problem is fixed in the ROOT source code, stop using this fix (and rebuild all your dependent libraries and executables from scratch again).

16

Can you open a JIRA ticket for the initial problem?

17

Understood & agreed. Wilco

18

JIRA -> ROOT -> ROOT-10756

19

So far, I refrained from opening a ticket as the JIRA system seemed to require an account. As my times as a student at CERN have been over for more than a decade, I do no longer have access to a CERN account.

If it is possible to create an “external” JIRA account (?), I would open a ticket (for the next issue, as apparently @Wile_E_Coyote already opened a ticket for the issue I reported - thank you for that),

20

If you have not created a “lightweight” CERN account up to now, then hold you breath. There is a plan to drop JIRA completely and switch to “Github Issues”.