Closed lachlansimpson closed 6 years ago
Hi, did you try this ./configure --with-bamtools=/path/to/bamtools --prefix=/path/to/prefix
Yep - the prefix didn't work :/
Actually, no need to use --prefix, just copy the executable to wherever you prefer.
Yep, that's what I did. Thanks!
Can it be specified what needs to be copied? I'm getting the same error: bash-4.1$ ./configure --with-bamtools=/usr/local/apps/bamtools/2.4.1/lib checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for ranlib... ranlib checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... no checking for sys/types.h... no checking for sys/stat.h... no checking for stdlib.h... no checking for string.h... no checking for memory.h... no checking for strings.h... no checking for inttypes.h... no checking for stdint.h... no checking for unistd.h... no checking api/BamReader.h usability... no checking api/BamReader.h presence... yes configure: WARNING: api/BamReader.h: present but cannot be compiled configure: WARNING: api/BamReader.h: check for missing prerequisite headers? configure: WARNING: api/BamReader.h: see the Autoconf documentation configure: WARNING: api/BamReader.h: section "Present But Cannot Be Compiled" configure: WARNING: api/BamReader.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to zhihao.ding@gmail.com ## configure: WARNING: ## ------------------------------------ ## checking for api/BamReader.h... no configure: error: The bamtools library must be installed (http://github.com/pezmaster31/bamtools). You can specify its path with the --with-bamtools=PATH option
Hi there,
Thanks for your interest in telseq. Could you try configuring it against this path (above the lib directory)
/usr/local/apps/bamtools/2.4.1
If the same errors happen again, then could you please try reinstalling bamtools with setting the following beforehand
export CXX=/path/to/gcc/gcc-4.8.1/bin/g++ export CC=/path/to/gcc/gcc-4.8.1/bin/gcc
The error will happen if bamtools and telseq are compiled using different compilers. And the above would fix that.
Best, Zhihao
I tried what you asked. I'm on a cluster, so the second option doesn't work for me. bash-4.1$ ./configure --with-bamtools=/usr/local/apps/bamtools/2.4.1 checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for ranlib... ranlib checking how to run the C++ preprocessor... g++ -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... no checking for sys/types.h... no checking for sys/stat.h... no checking for stdlib.h... no checking for string.h... no checking for memory.h... no checking for strings.h... no checking for inttypes.h... no checking for stdint.h... no checking for unistd.h... no checking api/BamReader.h usability... no checking api/BamReader.h presence... yes configure: WARNING: api/BamReader.h: present but cannot be compiled configure: WARNING: api/BamReader.h: check for missing prerequisite headers? configure: WARNING: api/BamReader.h: see the Autoconf documentation configure: WARNING: api/BamReader.h: section "Present But Cannot Be Compiled" configure: WARNING: api/BamReader.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to zhihao.ding@gmail.com ## configure: WARNING: ## ------------------------------------ ## checking for api/BamReader.h... no configure: error: The bamtools library must be installed (http://github.com/pezmaster31/bamtools). You can specify its path with the --with-bamtools=PATH option
Hi there,
This looks like a problem due to bamtools being compiled by another compiler. I would recommend install bamtools local to your home rather than using the system one. If installing bamtools is not an option for you, maybe give it a go with the precompiled binary? or the docker solution?
Best, Zhihao
The GLIBC version is too new for our cluster-- they won't update until spring. I can try the docker solution.
Hola
I've installed Bamtools in a non regular location, and created the appropriate environment module.
When loaded, the environment module appends the bamtools bin dir to PATH; sets LD_LIBRARY_PATH appropriately and CPLUS_INCLUDE_PATH/CPATHS appropriately.
Is there any chance telseq could be fixed to accomodate this (as per the gcc docs?)
Also, would be great if --prefix= worked with ./configure as well - we install software to a non regular place for use on a cluster.