Rhtslib fails to find liblzma.dylib on Mac OSX
1
0
Entering edit mode
Aaron Lun ★ 28k
@alun
Last seen 5 hours ago
The city by the bay

Pretty much as the title says. Installing via biocLite is fine, but calling:

library(Rhtslib)

... gives me the following error:

Error: package or namespace load failed for ‘Rhtslib’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/Users/lun01/Library/R/3.5/library/Rhtslib/libs/Rhtslib.so':
  dlopen(/Users/lun01/Library/R/3.5/library/Rhtslib/libs/Rhtslib.so, 6): Library not loaded: /usr/local/opt/xz/lib/liblzma.5.dylib
  Referenced from: /Users/lun01/Library/R/3.5/library/Rhtslib/libs/Rhtslib.so
  Reason: image not found

It seems my liblzma.dylib is located at /usr/lib instead. I'm not familiar enough with the Mac install process to know why the library location would differ between my machine and that used to build the binary for BioC, but it's not the first time something like this has happened, see https://stat.ethz.ch/pipermail/bioc-devel/2016-May/009317.html for a previous instance.

R version 3.5.0 RC (2018-04-16 r74624)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: OS X El Capitan 10.11.6

Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] zlibbioc_1.26.0 compiler_3.5.0 
Rhtslib • 1.8k views
ADD COMMENT
2
Entering edit mode
@herve-pages-1542
Last seen 18 hours ago
Seattle, WA, United States

Hi Aaron,

We have /usr/local/opt/xz/lib/liblzma.5.dylib on our Mac builders merida1 and merida2. It got installed as a dependency when we used brew to install some other component, maybe when we did brew install openssl or brew install python3 or brew install libxml2, hard to tell. For some reason, the linking step picks up this liblzma.5.dylib  instead of the one located in /usr/lib (which seems to be shipped with the OS). Anyway, it occurs to me that we shouldn't even need to link Rhtslib.so to liblzma on Mac because the htslib code is compiled as a static library (htslib.a) on this platform.

So I made the following change https://github.com/Bioconductor/Rhtslib/commit/f177ed4eff9c2ae861c7de0741fd4e663cc0bc7c and ported to the RELEASE_3_7 branch (Rhtslib 1.12.1). We might need to bump the versions of all packages that have Rhtslib in their LinkingTo field (e.g. csaw, bamsignals, deepSNV, etc...) in order to regenerate their Mac binaries which are also unnecessarily linked to /usr/local/opt/xz/lib/liblzma.5.dylib at the moment. We'll see how it goes. 

Cheers,

H.

 

ADD COMMENT
1
Entering edit mode

That seems to have addressed the issue. I consequently bumped the version of all packages that have Rhtslib in their LinkingTo field (e.g. csaw, bamsignals, deepSNV, etc...), but only in release (RELEASE_3_7 branch) for now. See for example commit 6ea86c79cfbc2b9d765ed31b35364b5eb39c7671 in the RELEASE_3_7 branch of csaw:

    Bump version to trigger propagation of new Mac binary
    
    Starting with Rhtslib 1.12.1, building the Mac binary of a package that
    is LinkingTo Rhtslib generates a binary that is no more linked to libz,
    libbz2, liblzma, and libcurl. So the Mac binary for csaw 1.14.1 won't
    depend on those libraries being installed or not on the user machine.

H.

 

ADD REPLY
0
Entering edit mode

Thanks Herve, looks good on my end as well.

ADD REPLY

Login before adding your answer.

Traffic: 791 users visited in the last hour
Help About
FAQ
Access RSS
API
Stats

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.

Powered by the version 2.3.6