Closed kelbstf closed 1 year ago
Hello,
i just wanted to add that the following attempt to nail the library path did not improve the situation:
> Sys.getenv("LD_LIBRARY_PATH") [1] "/usr/lib64/R/lib:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib/:/opt/hdf5-1.12.0/lib" > dyn.load("/opt/gsl-2.7/lib/libgsl.so")
And an additional attempt:
> Sys.setenv(LD_LIBRARY_PATH=paste("/opt/gsl-2.7/lib/", Sys.getenv("LD_LIBRARY_PATH"),sep=":")) > Sys.getenv("LD_LIBRARY_PATH") [1] "/opt/gsl-2.7/lib/:/opt/hdf5-1.12.0/lib:/usr/lib64/R/lib:/usr/lib/jvm/jre/lib/amd64/server:/usr/lib/jvm/jre/lib/amd64:/usr/lib/jvm/java/lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib/:/opt/hdf5-1.12.0/lib" >
It looks like the path is known and used at compile time, but missing at launch time?
Best
Hi there, thanks for this comprehensive post. I have had similar reports from other CentOS users, a system I am not familiar with. Not sure if R-devel or R-help would be appropriate here, it looks (as you say) to be a centos issue. If you resolve the issue, please let me know and I'll add it to the readme. Maybe remove /opt/R/4.1.0/lib/R/library/00LOCK-gsl/
?
Best wishes, Robin
Hello Robin,
thank you for your quick response and for your information about what you hear from your CentOS users. That pointed me to considering dynamic linker run-time bindings, which non-CentOS systems may not have to, as their os already ships with a proper release level. Because i had to compile it from scratch, i had opportunity to miss updating the dynamic linker run-time bindings afterwards ;-) After having caught up on that, the compilatin of GSL succeeded. That also explains why apparently the compilation succeeded, but the run time access during the test phase failed.
So from my perspective, this issue could be closed.
Best wishes
thanks for letting me know. Would you be able to send me a couple of sentences describing the problem and solution in a form suitable for adding to the README?
best wishes
Robin @.***>
On Fri, Jul 30, 2021 at 12:35 AM kelbstf @.***> wrote:
Hello Robin,
thank you for your quick response and for your information about what you hear from your CentOS users. That pointed me to considering dynamic linker run-time bindings, which non-CentOS systems may not have to, as their os already ships with a proper release level. Because i had to compile it from scratch, i had opportunity to miss updating the dynamic linker run-time bindings afterwards ;-) After having caught up on that, the compilatin of GSL succeeded. That also explains why apparently the compilation succeeded, but the run time access during the test phase failed.
So from my perspective, this issue could be closed.
Best wishes
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/RobinHankin/gsl/issues/14#issuecomment-889085215, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFFZUVDLRLJVVYOCJOHN4TT2FDKJANCNFSM5BEDBZVA .
Hello Robin,
sorry, i just realise i should have been more detailed to make it useful.
The core reason in my situation was that the stock CentOS7 GSL is too old (1.15-13.el7) for the gsl-wrapper. Therefore i compiled a current release of GSL, but installed into an "uncommon" place, with the intention to have multiple versions around (development server).
./configure --prefix=/opt/gsl-2.7
Since neither the executable of the OS-level GSL nor the GSL wrapper for R are installed in the default PATH (/lib, /usr/lib, ...), and the custom directory seems to be stored in -rpath-link at compile time and apparently not in -rpath for the run time, shared objects are looked up as a last resort in the directories specified by /etc/ld.so.conf. Which i had missed to add after having compiled GSL and before attempting to install(/compile) the "gsl" wrapper in R.
After having fixed that via
vi /etc/ld.so.conf.d/libgsl-x86_64.conf /opt/gsl-2.7/lib/
installation of the gsl wrapper from CRAN in R with no additional specifications worked immediately via:
install.packages('gsl')
That's at least my understanding of why this worked. I am not sure about the "-rpath" explanation, but it would match the sgnificant behaviour that while the compilation worked, the test call to the resulting executable out of the "/tmp" immediately afterwards failed?
Would that fit your bill?
Best wishes
Hello,
i fail to install "gsl" in R 4.1.0 from CRAN on a CentOS7.8 with gsl 2.7 compiled from sources:
The strange thing is that the actual compilation seems to work perfectly fine:
Session:
Just the access to the result fails. And i see no reason, because:
The old gsl 1.0 had been removed prior to compiling 2.7, so there is only one instance around... Does any one have an idea?