Does Rhtslib currently work on Windows?
Entering edit mode
Shian Su ▴ 40
Last seen 10 months ago
Walter and Eliza Hall Institute of Medi…

I'm helping develop scPipe which we're currently trying to contribute to Bioconductor. Unfortunately the are build issues on Windows that I am unable to resolve. Namely the package is unable to load its own DLL.

I noticed that link2Rhtslib does not build on Windows with the error

localfunc.o:localfunc.c:(.txt+0x45): undefined reference to `bios_zlibversion'

collect2.exe: error: ld returned 1 exit status

no DLL was created

Also that Rhtslib currently skips building on Windows. So I am wondering if Rhtslib (or htslib) currently supports Windows at all or if I'm on a wild goose chase.

Rhtslib htslib package • 1.5k views
Entering edit mode
Last seen 7 days ago
United States

Wow some of the StackOverflow discussion was quite hostile!

The build system link with no Windows build shows that the Windows builds as a whole failed to report; Rhtslib is supported on Windows. For reference, several packages, e.g., csaw and bamsignals, link to Rhtslib and are available on Windows.

Remember to use the 'devel' version of Bioconductor (hence devel build reports) when developing packages.

And I know you've bounced around from your contribution to StackOverflow to here, but the _correct_ place to ask about Bioconductor package development is on the bioc-devel mailing list (the support site is meant for end-user questions).

The undefined reference is to 'bios_zlibversion' but the symbol is bioc_zlibVersion -- is that a copy-paste error?

I don't have windows access at the moment, but suggest removing the explicit reference to zlib in and adding Rhtslib to the Imports: field of the DESCRIPTION file. In terms of debugging, I'd get RStudio out of the way and try to build / install from the DOS / PowerShell prompt, R CMD INSTALL scPipe (R has to be on the PATH environment variable, or the full path specified).



Entering edit mode

Yes that `zlibVersion` was a typo, wasn't logged into bioconductor on my Windows testing laptop so I typed out the error message. Thanks for the help, I'll try it out once I'm infant of a Windows laptop again.

Entering edit mode

Thanks so much Martin, the necessary code was to add `import(Rhtslib)` to the `NAMESPACE`, which I did via ROxygen's `@import` for consistency.  I still needed the `zlibbioc::pkgconfig()` code because I actually reference `zlib` directly in some of my c++. I'll post these to the dev mailing list in the future, it was just too tempting to use the nice formatting facilities of this site.

Entering edit mode
Mike Smith ★ 5.9k
Last seen 7 hours ago
EMBL Heidelberg

First off, I'm not sure I can actually answer your headline question. I can install Rhtslib fine on Windows, but get the same error you do when trying to build link2Rhtslib. However I think I can at least get your package to load on Windows.

If you want to use zlibbioc then I think you should link against the pre-compiled static library on Windows. It looks like you got some decent advice on StackOverflow, and the error LoadLibrary failure: The specified module could not be found is a result of linking against the shared library during compilation, and its location can't be resolved when you then try to load scPipe.dll

You can fix this by using zlibbioc::pkgconfig("PKG_LIBS_static") in your

However, I think this will lead to a new set of problems, and I'm not sure you should use zlibbioc at all. In my experience I find the interaction between zlibbioc and other packages that are also ship pre-compiled Windows binaries (like Rhtslib) pretty baffling, and when I've tried to use it, I've ended up just resorting to using system versions of zlib.

In your case Rhtslib already links against a version of zlib, and includes -lz in it's compilation flags, which will probably be a system version of zlib since no path is specified. If you also include zlibbioc I think there's a good chance your compiler will complain of multiple definitions of the same functions and fail.

If you remove any reference to zlibbioc (in and DESCRIPTION) then your code will link to the system library. I understand the desire to use stable library versions that don't require external installation, but zlib is pretty ubiquitous and I'm not sure Rhtslib will work without it anyway, so I think that's a safe option here.

Entering edit mode

zlib isn't available on typical end-user Windows installations. This was the primary motivation for zlibbioc.

At runtime the DLL needs to be loaded, but since Rhtslib (or zlibbioc, which Rhtslib imports) isn't loaded, the DLL isn't found. Probably the instructions in Rhtslib need to be updated to say Imports: Rhtslib.

zlibbioc mangles zlib names, so there are no conflicts with system libraries.

The technical problem with using dynamic libraries on Windows is that the version discovered depends on the order they appear on the (run time) search path. If there are different DLL with the same name, the one actually used is not consistent. However, if zlibbioc is loaded in the R session (implicitly via Imports: Rhtslib or explicitly by Imports: zlibbioc), name mangling ensures that there is only one version of the zlibbioc DLL, so no problem using the shared library.

Entering edit mode

Cool, this works for me.  I might have some modifications to make to Rhdf5lib and beachmat now!

Does the name mangling not happen to the static version of zlib?  I seem to get multiple definition errors when I try to link against that, but they disappear when using the shared version.

Entering edit mode

Name mangling should happen with the static library too. Are the duplicate symbols preceeded by bioc_, e.g., bioc_gzopen ? Compile time or run time? Maybe Rhtslib arranges for the dynamic library, your code for the static library, so two versions available. Be sure to remove previous build products between installation attempts. A reproducible example would be great.


Login before adding your answer.

Traffic: 292 users visited in the last hour
Help About
Access RSS

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

Powered by the version 2.3.6