Page MenuHomeFreeBSD

math/R: Update to version 4.0.0
ClosedPublic

Authored by jrm on Apr 26 2020, 3:47 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Nov 17, 7:36 PM
Unknown Object (File)
Sat, Nov 16, 6:20 PM
Unknown Object (File)
Sat, Nov 16, 1:12 AM
Unknown Object (File)
Thu, Nov 7, 2:28 PM
Unknown Object (File)
Wed, Oct 23, 11:36 PM
Unknown Object (File)
Oct 1 2024, 10:30 PM
Unknown Object (File)
Oct 1 2024, 6:38 AM
Unknown Object (File)
Sep 18 2024, 10:20 AM
Subscribers

Details

Summary

Upstream changes:
https://stat.ethz.ch/pipermail/r-announce/2020/000653.html

PR:
Submitted by: wen
Reported by:

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jrm requested review of this revision.Apr 26 2020, 3:47 AM
math/R/files/extra-patch-src_modules_lapack_Makefile.in
8 ↗(On Diff #70996)

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
thierry added a subscriber: thierry.

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
This revision is now accepted and ready to land.Apr 26 2020, 6:27 PM

@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.

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.

In D24572#543344, @jrm wrote:

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.

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 :)

In D24572#543344, @jrm wrote:

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.

I build tested some Bioconductor apps like Sleuth and DESeq2 and they seem OK as well.

Standarize shared library installation so they are picked up by ldconfig

This revision now requires review to proceed.May 5 2020, 4:24 AM

@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.

In D24572#543708, @jrm wrote:

@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.

@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 :-)

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.

@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
In D24572#543744, @jrm wrote:

@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

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 ;)

This revision was not accepted when it landed; it landed in state Needs Review.May 5 2020, 4:08 PM
Closed by commit rP534095: math/R: Update to version 4.0.0 (authored by jrm). · Explain Why
This revision was automatically updated to reflect the committed changes.