Duplicate symbols with libbwa

[rob-p]

Hi,

First, thank you all for htslib. This is an amazing resource and incredibly useful library. I have a project that includes uses both libbwa and libhts. However both of these (linked statically) seem to include the same symbol _ksprintf. The specific error is:

duplicate symbol _ksprintf in:
    ../../external/install/lib/libhts.a(kstring.o)
    ../../external/install/lib/libbwa.a(kstring.o)
ld: 1 duplicate symbol for architecture x86_64

any suggestions about how to avoid this?

Thanks! Rob

[daviesrob]

I'm having trouble getting this to happen, at least with my small test program. How did you build htslib and bwa, and what are you trying to build that joins them together?

[valeriuo]

Also, are you building from Xcode and do you have -ObjC set in your linker flags?

[rob-p]

Hi @daviesrob,

Thanks for the quick reply. I build htslib with a regular ./configure --prefix=<INSTALL_DIR> && make install. I am building these together for our project Salmon. We use some internal functions of bwa, so we depend on libbwa.a. Currently, we use Staden's io_lib for SAM and BAM parsing, but I would like to move to htslib, as it is a more canonical SAM/BAM parser, with more features, that is updated more frequently. The build process first builds libbwa.a then builds libhts.a, and then they are both linked together when building the Salmon binary. This problem popped up only when attempting to switch to htslib, as io_lib does not include the _ksprintf symbols.

@valeriuo : I am building from the command line using CMake and Make (in this case with the default OSX compiler --- i.e. Apple Clang). I don't have -ObjC set. All of the code I'm building is either C or C++ (specifically C++11).

Thanks, Rob

[rob-p]

Hi all,

I realized the awesome SeqLib library links both libbwa and libhts. So, I dug into things a little bit, and realized they actually had to hack the kstring.c/kstring.h in bwa as so. The fact that you have to actually modify the source of one or the other library is not the most satisfying solution, but it does, of course, work in my case.

Best, Rob

[jmarshall]

Seeing as HTSlib is a widely-used library packaged and distributed in both shared and static form (and is probably the canonical source of third-party use of shared klib functionality), while libbwa.a is a non-installed intermediate file produced while building the bwa executable which a handful of other projects reach into and link against, it seems to me that the appropriate place to work around this is in libbwa.

Ideally bwa's build system could be patched so you could (optionally) compile bwa's source files against HTSlib's edition of the klib headers and omit the k*.o files supplied by HTSlib from libbwa.a. This is complicated by the fact that HTSlib provides only a subset of the klib facilities used by bwa.

The easy way to work around this would be to patch bwa's klib header like this:

diff --git bwa/kstring.h bwa/kstring.h
index fe7fa95..13d374f 100644
--- bwa/kstring.h.orig
+++ bwa/kstring.h
@@ -20,6 +20,11 @@ typedef struct __kstring_t {
 } kstring_t;
 #endif
 
+// Avoid conflicting with HTSlib's kstring.c functions, to enable
+// linking against both libbwa and libhts. We #define each function
+// in BWA's kstring.c, which is currently just one function.
+#define ksprintf bwa_ksprintf
+
 static inline void ks_resize(kstring_t *s, size_t size)
 {
        if (s->m < size) {

Salmon could achieve this without patching bwa source code at all by building its copy of libbwa.a with -Dksprintf=bwa_ksprintf in the compilation flags.