Open chapmanb opened 6 years ago
Something like that may be a useful workaround to get past a pain point, but it is a terrible hack that should not be checked in. This htslib change, distasteful though it is, should be invisible outside htslib.
I suspect what is happening here is that you are compiling with the 1.6 headers but accidentally linking with an older pre-1.6 libhts.a. Is this possible?
John -- agreed this is an ugly hack and I'd welcome a better solution. Practically this happens when building pindel inside bioconda so it starts with a clean empty Docker environment that only injects the 1.6 build. Unless the bioconda 1.6 htslib is somehow broken, I'm not sure how we'd get the older versions in there. I'm definitely not an expert on pindel building or htslib so am kind of out of my element here and would welcome better ideas to fix this.
I'm not going to defend the HTSlib change, but I was surprised that I was unable to reproduce this sort of problem when building third-party software against it. First step: send me a full log from your bioconda build and I can take a look at it. Though really it is @daviesrob's problem :smile:
Looks like this was due to a missing extern "C"
in htslib/ksort.h
(see #76). One should appear on the develop branch soon.
Apologies for the inconvenience...
The fix has now been pushed to htslib's develop branch.
htslib 1.6 changed how ksort is exposed, internalizing drand48 into hts_drand48 (samtools/htslib#559). This caused a lookup error during compiling:
Triggered when initializing ksort:
https://github.com/chapmanb/pindel/blob/b706fba61c64a11fb1d3716d501fd2f4d8992e29/src/reader.cpp#L67
This works around the issue by referencing hts_drand48 to drand48.
I'm not sure if this is the best long term fix but hopefully will be a workaround for folks or lead to discussion of a better approach to take.