#77 staden-2.0.0b7-src/gap5/Makefile does not include "-lbam"

Gap5 (15)
Martin Mokrejs

i686-pc-linux-gnu-gcc -L/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib -o tg_index tg_index.o -ltgap -lgap5 -lprimer3 -lz -ltk_utils -lseq_utils -L/usr/lib -ltk8.5 -L/usr/lib -ltcl8.5 -lX11 -lXft -lX11 -lfreetype -lfontconfig -lXrender -lX11 -lpthread -ldl -lpthread -lieee -lm -lz -lmisc -lm -ldl
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `bam_plbuf_set_mask'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `samclose'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `bam_nt16_rev_table'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `sam_tbl_get'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `samopen'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `bam_plbuf_push'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `bam_plbuf_init'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `sam_tbl_destroy'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `samread'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `bam_plbuf_destroy'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `sam_header_parse2'
/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/lib/libgap5.so: undefined reference to `sam_header2tbl'
collect2: ld returned 1 exit status
make[1]: *** [tg_index] Error 1
make[1]: Leaving directory `/var/tmp/portage/sci-biology/staden-2.0.0/work/staden-2.0.0b7-src/gap5'

Adding -lbam helps, the question now is where should that be defined. I had a look into staden-2.0.0b7-src/gap5/Makefile at inherits values from upstream staden-2.0.0b7-src/Makefile, but I cannot find where it failed.

config.log does not help:

configure:6472: checking for bam_header_read in -lbam
configure:6507: i686-pc-linux-gnu-gcc -o conftest -O2 -march=pentium4 -mmmx -msse -msse2 -pipe -fno-strict-aliasing -ggdb -I/include -I/include -I/include -L/lib -lbam -lz conftest.c -lbam >&5
configure:6513: $? = 0
configure:6531: result: yes
configure:6544: checking bam.h usability
configure:6561: i686-pc-linux-gnu-gcc -c -O2 -march=pentium4 -mmmx -msse -msse2 -pipe -fno-strict-aliasing -ggdb -I/include -I/include -I/include conftest.c >&5
configure:6567: $? = 0
configure:6581: result: yes
configure:6585: checking bam.h presence
configure:6600: i686-pc-linux-gnu-gcc -E -I/include -I/include -I/include conftest.c
configure:6606: $? = 0
configure:6620: result: yes
configure:6648: checking for bam.h
configure:6655: result: yes
configure:6690: checking if samtools version >= 0.1.3
configure:6715: result: yes


  • James Bonfield
    James Bonfield

    Your config.log implies it did add -lbam and this was sufficient to link with the bam_header_read function, but I wonder why it's not then using it. The staden build system is a bit unorthodox. Originally it was just a standard bunch of makefiles not using autoconf at all. This later was modified by requiring $MACHINE environment to be set and having all the Makefiles include $(MACHINE).mk - we then could write linux.mk, solaris.mk, even windows.mk makefile stubs for each platform.

    To autoconf-ify the entire package is a huge amount of work, but instead I decided to cheat a bit and basically have the configure script generate system.mk and then each Makefile includes this. It avoids needing to set MACHINE environment and the appropriate machine config is generated for you based on configure and --with parameters. My own system.mk has this for samtools in it:

    #-- samtools
    SAMTOOLS_LIB = -L/nfs/disk54/badger/packages/samtools-0.1.7a -lbam -lz
    SAMTOOLS_INC = -I/nfs/disk54/badger/packages/samtools-0.1.7a

    (I did configure "--with-samtools=/nfs/disk54/badger/packages/samtools-0.1.7a" where that directory contains a built, but not installed, copy of 0.1.7 with local mods perhaps - I forget where the "a" came from.)

    So it's your system.mk that would need to be modified to add -lbam to it.

    system.mk is derived from system.mk.in, with the relevant lines being:

    #-- samtools

    The ax_lib_samtools.m4 configure component using autoconf's AC_SUBST function to replace these placeholders with the appropriate text. See:


    (If you change this, rerun the bootstrap program from SVN to do the necessary autoconf commands.)

    I'm confused though why this didn't work. What does your system.mk file contain?

  • James Bonfield
    James Bonfield

    • status: open --> open-accepted
  • Martin Mokrejs
    Martin Mokrejs


  • Martin Mokrejs
    Martin Mokrejs

    File ac_stubs/ax_lib_samtools.m4 contains:

    # This macro will check for the existence of samtools 'bam' library.
    # (http://samtools.sourceforge.net/). It does this by checking for the
    # header file ibam.h and the bam library object file. These are
    ____________^^^^^^ I have /usr/include/bam.h instead.

    Am I missing some samtools file?

    # equery files samtools
    * Searching for samtools ...
    * Contents of sci-biology/samtools-0.1.7a:

  • Martin Mokrejs
    Martin Mokrejs

    config.log says:


    config.status hence says:

    s,@SAMTOOLS_VERSION@,|#_!!_#|0.1.7 ,g

    I think the generated configure overwrites the *FLAGS somewhere. ;-)

  • James Bonfield
    James Bonfield

    The ibam.h is a typo, it should be bam.h.

    It's intriguing that you have a "proper" samtools install in /usr, even with /usr/include/bam.h. Samtools doesn't even have a "make install" target, so I've always had to guess whether we should include <bam.h>, <sam/bam.h> or maybe <samtools/bam.h>. This is why typically I just use --with-samtools as a samtools compiled source tree instead.

    Am I right in thinging this is a gentoo package build? I'm also intrigued to know whether libbam.a was built using -fPIC or not. If not you may run into other problems as I use libbam.a when building a run-time library (libgap5.so) which requires position independent code - particularly on x86-64 targets. This isn't the default compilation flags for samtools though.

    Anyway, perhaps there's a problem with the ax_lib_samtools.m4 when not needing to use --with-samtools anywhere given the system installed location. I'm thinking that the SAMTOOLS_LDFLAGS line (102) in ax_lib_samtools.m4 shortly after the <Maybe it works "out of the box"?> comment requires a -lbam added to it too. I've committed this change to svn.

  • Martin Mokrejs
    Martin Mokrejs

    Your changes to ax_lib_samtools.m4 work for me, thanks.

    Regarding the samtools header files, I just placed them when I found staden looks for them. So, the location was reverse-engineered. :-)

    I am building staden with -fPIC but not samtools. Hmm, I am on 32bit x86 so this is probably no issue for me. I will fix the samtool package in Gentoo as well. ;-)

  • James Bonfield
    James Bonfield

    I believe i386 works ok, but x86-64 may well need -fPIC. The problem is that although libbam.a is a static package and is assumed to be linked into an application (so non-pic code is fine), my use of it is linking libbam.a into a dynamic .so file which gets loaded on demand (as a Tcl extension). The usage falls between the usual normal cases I guess.

    Marking this problem as resolved though. Thanks for finding it and assistance.

  • James Bonfield
    James Bonfield

    • status: open-accepted --> closed-fixed