[R] make install libgfortran.so.5: cannot open shared object file: No such file or directory; conftest.c:1:10: fatal error: jni.h: No such file or directory

[Ivan Krylov]

В Mon, 21 Nov 2022 10:19:36 -0500
Rob Kudyba <rk3199 using columbia.edu> пишет:

> I edited the last line to be:
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/gcc-11.2/lib64 then
> make install errored with:
> /path/to/R-4.2.2/bin/exec/R: error while loading shared libraries:
> libpcre2-8.so.0: cannot open shared object file: No such file or
> directory
> 
> So it appears that the same issue happens for PCRE! I then edited the
> line to be:
> export
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/gcc-11.2/lib64:/path/to/pcre2-10.35/lib
> 
> Then make install finished with:
> Successfully remade target file `install'.

Does the installed copy of R work?

Are you running make install as root? Programs starting as root are wary
of environment variables such as LD_LIBRARY_PATH and may ignore or
unset them while starting up (otherwise it would be trivial to load user
code into setuid root binaries and take over the system). You may have
to load the module again after you obtain the superuser privileges.

> I ran the 1st command and then added the 'read' to the file. I'm not
> following what should've happened? I didn't need to include the back
> ticks,`, in the file, correct?

Yes, I meant to omit the backticks.

What I'm suggesting to perform is Linux process debugging:

1) Make etc/ldpaths hang just before R is (unsuccessfully) launched by
adding an I/O operation that you can control.

2) While make install -> (lots of child processes) -> bin/R is hung,
run `top`, `htop`, or any other process manager to have a look at the
process tree. There should be your shell process, the Make process, and
a number of child shell processes. The grand-(grand-...)child should be
sleeping in I/O.

3) Using either your process manager or the command

 </proc/${pid}/environ tr '\0' '\n' | grep LD_LIBRARY_PATH

(substituting the PID instead of ${pid}), see which processes in the
tree you observed in (2) have the correct value of LD_LIBRARY_PATH and
which don't.

Once you know which process is responsible for losing LD_LIBRARY_PATH,
it should be possible to take a look at its command line, source code,
documentation to find out why it does that and whether it's possible to
prevent it from doing that.

"R Installation and Administration" [1] says that the R build process
remembers the library paths to put into LD_LIBRARY_PATH, but only if
they are specified in the LDFLAGS parameter, so if there's a set of
library paths that's not expected to be normally present in
LD_LIBRARY_PATH, perhaps it's best to mention them explicitly in the
./configure call.

-- 
Best regards,
Ivan

[1] https://cran.r-project.org/doc/manuals/R-admin.html