search

eddelbuettel / rcppziggurat

Rcpp bindings for different Ziggurat RNG implementations
Other
12 stars 4 forks source link

Is it supposed to link to GSL directly? Dependency is not declared, but it links to GSL #21

Closed barracuda156 closed 5 months ago

barracuda156 commented 5 months ago

@eddelbuettel Looks like it links directly to gsl, when it is available, but that is not declared as a dependency, so things may suddenly break. This is what happened now after gsl update, which required revbump of its dependents, and I missed RcppZiggurat, since it was not supposed to depend on gsl directly:

* installing *source* package ‘regda’ ...
** package ‘regda’ successfully unpacked and MD5 sums checked
** using staged installation
** R
** byte-compile and prepare package for lazy loading
Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/RcppZiggurat/libs/RcppZiggurat.so':
  dlopen(/opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/RcppZiggurat/libs/RcppZiggurat.so, 6): Library not loaded: /opt/local/lib/libgsl.27.dylib
  Referenced from: /opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/RcppZiggurat/libs/RcppZiggurat.so
  Reason: image not found
Calls: <Anonymous> ... asNamespace -> loadNamespace -> library.dynam -> dyn.load
Execution halted
ERROR: lazy loading failed for package ‘regda’

(Another question is why regda calls RcppZiggurat, but that is a question to its upstream.)

Checking directly:

36-231% otool -L /opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/RcppZiggurat/libs/RcppZiggurat.so
/opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/RcppZiggurat/libs/RcppZiggurat.so:
    RcppZiggurat.so (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libMacportsLegacySupport.dylib (compatibility version 1.0.0, current version 1.2.3)
    /opt/local/lib/libgsl.27.dylib (compatibility version 28.0.0, current version 28.0.0)
    /opt/local/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 511.1.0)
    /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.32.0)
    /opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/lib/libR.dylib (compatibility version 4.4.0, current version 4.4.0)
    /opt/local/lib/libgcc/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 117.0.0)

To be clear, we do not do anything to force RcppZiggurat link to gsl. There are no patches applied to RcppZiggurat from MacPorts side on any arch and OS version.

eddelbuettel commented 5 months ago

The dependency is via RcppGSL and that has it declared.

eddelbuettel commented 5 months ago

This is what happened now after gsl update, which required revbump of its dependents,

Yes, I know. It is irritating and happens because the R package managers is (generally) not integrated with the system package manager so the latter may update something that breaks the former.

But when you integrate system and package manager as I have done with r2u and its bridge to apt (via R's bspm package) then you are safe: The RcppZiggurat package depends on the RcppGSL package which has a proper versioned depends on the GSL run-time library the package manager will now keep.

barracuda156 commented 5 months ago

@eddelbuettel Ok, perhaps I misunderstand the situation. I thought that since RcppGSL links to gsl, dependents of the former link to it, but not directly to gsl. This does not seem to be the case though. If this is correct and not an error, then we must add direct dependency to gsl to every dependent of RcppGSL.

In my example RcppGSL has been revbumped and it linked to the new gsl version:

36-231% otool -L  /opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/RcppGSL/libs/RcppGSL.so
/opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/library/RcppGSL/libs/RcppGSL.so:
    RcppGSL.so (compatibility version 0.0.0, current version 0.0.0)
    /opt/local/lib/libMacportsLegacySupport.dylib (compatibility version 1.0.0, current version 1.2.99)
    /opt/local/lib/libgsl.28.dylib (compatibility version 29.0.0, current version 29.0.0)
    /opt/local/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 511.1.0)
    /opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.32.0)
    /opt/local/Library/Frameworks/R.framework/Versions/4.4/Resources/lib/libR.dylib (compatibility version 4.4.0, current version 4.4.0)
    /opt/local/lib/libgcc/libgcc_s.1.1.dylib (compatibility version 1.0.0, current version 1.1.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 117.0.0)
eddelbuettel commented 5 months ago

You may do as you please in your binary distribution but you filed an issue that is not one under the CRAN specs. RcppZiggurat needs RcppGSL. RcppGSL needs GSL. We generally do not store recursive dependencies at the top-level package.

barracuda156 commented 5 months ago

The RcppZiggurat package depends on the RcppGSL package which has a proper versioned depends on the GSL run-time library the package manager will now keep.

@eddelbuettel I am sorry, but it seems not to work this way, that is my point. Rebuilding RcppGSL does not fix linking for RcppZiggurat.

To be clear, I am not asking you to change anything, I just need to know if the direct linking, independent from RcppGSL, is the correct behavior. If it is, we just add a direct dependency, and no error will arise.

eddelbuettel commented 5 months ago

I cannot help you with your OS question.

But consider that the package is clean at CRAN:

image

This means dependencies are resolved correctly. That may for some OSs mean static linking: I have no idea, and I do not need to know. R resolves this for me.

Now, on Linux I have

edd@rob:~$ ldd /usr/local/lib/R/site-library/RcppZiggurat/libs/RcppZiggurat.so 
        linux-vdso.so.1 (0x00007ffcdffe3000)
        libgsl.so.27 => /lib/x86_64-linux-gnu/libgsl.so.27 (0x0000767c5d000000)
        libR.so => /lib/libR.so (0x0000767c5ca00000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000767c5c600000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000767c5d398000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000767c5d374000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000767c5c200000)
        libgslcblas.so.0 => /lib/x86_64-linux-gnu/libgslcblas.so.0 (0x0000767c5d330000)
        libblas.so.3 => /lib/x86_64-linux-gnu/libblas.so.3 (0x0000767c5d2c6000)
        libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 (0x0000767c5cfac000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x0000767c5cf11000)
        libdeflate.so.0 => /lib/x86_64-linux-gnu/libdeflate.so.0 (0x0000767c5d2b2000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x0000767c5cedf000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x0000767c5cecc000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x0000767c5cead000)
        libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x0000767c5ce80000)
        libicuuc.so.70 => /lib/x86_64-linux-gnu/libicuuc.so.70 (0x0000767c5c005000)
        libicui18n.so.70 => /lib/x86_64-linux-gnu/libicui18n.so.70 (0x0000767c5bc00000)
        libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1 (0x0000767c5c9ad000)
        /lib64/ld-linux-x86-64.so.2 (0x0000767c5d4d9000)
        libopenblas.so.0 => /lib/x86_64-linux-gnu/libopenblas.so.0 (0x0000767c59928000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x0000767c5c979000)
        libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x0000767c5c925000)
        libicudata.so.70 => /lib/x86_64-linux-gnu/libicudata.so.70 (0x0000767c57c00000)
        libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5 (0x0000767c57800000)
        libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x0000767c5c537000)
        libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x0000767c5c8f9000)
        libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x0000767c5ce76000)
        libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x0000767c5ce69000)
        libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x0000767c5c8f2000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x0000767c5c8de000)
edd@rob:~$

and that is why e.g. RcppZiggurat in r2u does have a dependency declared because the ldd makes it so under the way apt and ,deb packages works:

edd@rob:~$ docker run --rm -ti rocker/r2u:noble
root@672b5f55886f:/# apt update -qqq
root@672b5f55886f:/# apt-cache show r-cran-rcppziggurat
Package: r-cran-rcppziggurat
Architecture: amd64
Version: 0.1.6-1.ca2404.1
Priority: optional
Section: gnu-r
Maintainer: Dirk Eddelbuettel <edd@debian.org>
Installed-Size: 688
Depends: libc6 (>= 2.38), libgcc-s1 (>= 3.0), libgsl27 (>= 2.7.1), libstdc++6 (>= 13.1), r-base-core (>= 4.4.0), r-api-4.0, r-cran-rcpp, r-cran-rcppgsl
Suggests: r-cran-rbenchmark, r-cran-microbenchmark, r-cran-lattice, r-cran-knitr, r-cran-rmarkdown, r-cran-pinp
Filename: pool/dists/noble/main/r-cran-rcppziggurat_0.1.6-1.ca2404.1_amd64.deb
Size: 409454
MD5sum: d7d04c573b654ba7c06fd2131dd92089
SHA1: 1696a924129fb2e36683ebd36e4c2290116a63c3
SHA256: 5e776926b1013049464a7d324dafde98f76042914dea0092260f1e2f596199fc
SHA512: f61b490612a202893f2179d2dcab633f801789370483eb3b4601cbc43bf08fe5c011953d21bd0d2ae368599355322d10d57009f179e1f0ad652dff19ca0fe002
Homepage: https://cran.r-project.org/package=RcppZiggurat
Description: CRAN Package 'RcppZiggurat' ('Rcpp' Integration of Different "Ziggurat" Normal RNGImplementations)
 The Ziggurat generator for normally distributed random numbers, originally
 proposed by Marsaglia and Tsang (2000, <doi:10.18637/jss.v005.i08>) has been
 improved upon a few times starting with Leong et al (2005,
 <doi:10.18637/jss.v012.i07>).  This package provides an aggregation in order
 to compare different implementations in order to provide an 'faster but good
 enough' alternative for use with R and C++ code.
Description-md5: 

root@672b5f55886f:/#

So once again I believe you need to address that in your distribution of this repo in binary form. I do too.

barracuda156 commented 5 months ago

Thank you, you did help. This info is enough.