Upstream changes:
https://stat.ethz.ch/pipermail/r-announce/2020/000653.html
PR:
Submitted by: wen
Reported by:
Details
Details
- Reviewers
wen jwb rhurlin thierry - Commits
- rP534095: math/R: Update to version 4.0.0
Diff Detail
Diff Detail
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 30729 Build 28457: arc lint + arc unit
Event Timeline
| math/R/files/extra-patch-src_modules_lapack_Makefile.in | ||
|---|---|---|
| 8 | Hi Joseph, Many thanks for this extensive update, very appreciated! Your update of R-4.0.0 builds and runs fine, btw. What I am wondering about is, shouldn't we better use something like - @BUILD_LTO_CHECK_FALSE@$(DYLIB_LINK) -o $@ $(LIBOBJECTS) -Wl,-soname,libRlapack.so.%%LIBVER%% @BLAS_LIBS@ $(Rlapack_la_LIBADD) + @BUILD_LTO_CHECK_FALSE@$(DYLIB_LINK) -o $@ $(LIBOBJECTS) -Wl,-soname,libRlapack.so.%%MAJORVER%% @BLAS_LIBS@ $(Rlapack_la_LIBADD) to get the major version appended to the libs instead of the full numbered version of the lib? Don't we better need shared libraries with only major number for ldconfig? If this is true, wouldn't this also be the case for all three R libs under ${LOCALBASE}/lib/R/lib/: libR.so.4, libRblas.so.4, libRlapack.so.4 ? Many other libs under ${LOCALBASE}/lib/ have all three 'names' of a libs, two of them are links to the full numbered one, e.g. libzstd.so -> libzstd.so.1.4.4 libzstd.so.1 -> libzstd.so.1.4.4 libzstd.so.1.4.4 | |
Comment Actions
Just after upgrading R:
$ ldd /usr/local/lib/libexec/rkward.rbackend /usr/local/lib/libexec/rkward.rbackend: libR.so.3.6 => not found (0) libRlapack.so.3.6 => not found (0) libRblas.so.3.6 => not found (0) …
But it is suffficient to bump its PORTREVISION and to rebuild math/rkward-kde to fix the problem:
Index: math/rkward-kde/Makefile =================================================================== --- math/rkward-kde/Makefile (revision 531138) +++ math/rkward-kde/Makefile (working copy) @@ -3,6 +3,7 @@ PORTNAME= rkward PORTVERSION= 0.7.1 +PORTREVISION= 1 CATEGORIES= math MASTER_SITES= KDE/stable/${PORTNAME}/${DISTVERSION:C/b//}/src PKGNAMESUFFIX= -kde
Comment Actions
@rhurlin_gwdg.de Thanks. I'll take a closer look. I don't think it was arbitrary to set the library version that way, but I'll have to try and remember if there was a good reason.
@thierry Thanks. I'll also bump PORTREVISION for math/rkward-kde.
Comment Actions
I build tested everything and it all looks fine. Unless you have concrete objections, I am going to go ahead and commit this. @rhurlin_gwdg.de, I think the library versions we are making up are somewhat arbitrary in this case, since, after a long discussion with upstream, they do not really intend for them to be share libraries, but dynamically loaded. We are bumping dependencies manually, so I think things are fine. If you have other reasons that I am missing, we can always adapt later.
Comment Actions
Thanks for the explanation. I asked for it because ldconfig does not see the R libraries (libR.so, libRblas.so, and libRlapack.so). If we do not need them as shared ones for other ports, all seems fine.
Now I am looking forward to your commit of math/R 4.0.0 :)
Comment Actions
I build tested some Bioconductor apps like Sleuth and DESeq2 and they seem OK as well.
Comment Actions
@rhurlin_gwdg.de I believe this should do the trick for the shared libraries.
I'm re-testing all the dependencies to be certain this doesn't break any builds. If I don't hear any objections and if everything builds fine, I'll proceed with the update soon.
Comment Actions
@jrm Many thanks for this update. I just built and installed again with your 'trick' for the shared libraries and it seems to work fine:
#ldconfig -r | grep libR
1845:-lR.4 => /usr/local/lib/R/lib/libR.so.4
1846:-lRblas.4 => /usr/local/lib/R/lib/libRblas.so.4
1847:-lRlapack.4 => /usr/local/lib/R/lib/libRlapack.so.4
This is exactly the behaviour I meant in my initial comment :-)
Comment Actions
I have not yet updated with your latest version, but with the first one, pkg-config already reported:
$ pkg-config libR --libs
-Wl,--export-dynamic -fopenmp -L/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9 -B/usr/local/bin -fstack-protector-strong -L/usr/local/lib/R/lib -lR -lRblas
and I guess that most consumers use pkg-config.
Comment Actions
@thierry I think we are still OK.
% pkg-config libR --libs -Wl,--export-dynamic -fopenmp -L/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9 -B/usr/local/bin -fstack-protector-strong -L/usr/local/lib/R/lib -lR -lRblas
Comment Actions
I also think so. With latest version, not surprising, I get the same on my box:
#pkg-config libR --libs -Wl,--export-dynamic -fopenmp -L/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc9 -L/usr/local/lib/gcc9 -B/usr/local/bin -fstack-protector-strong -L/usr/local/lib/R/lib -lR -lRblas
And 'ldconfig -r' is fine ;)