-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compilation on R 4.1.0 fails #14
Comments
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 Best wishes, Robin |
Hello Robin, thank you for your quick response and for your information about what you hear from your CentOS users. 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
<#14 (comment)>, 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. ./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. 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. 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?
The text was updated successfully, but these errors were encountered: