--version not showing a bowtie2 version

[djbradshaw2]

Dear Whom It May Concern,

I ran into this problem while using humann3 from biobakery. It was not recognizing bowtie2 because it seems it could not recognize a version https://forum.biobakery.org/t/humann-3-cannot-call-bowtie2-version/576/5. --version does not actually print a version number, near as I can tell. I create a clean environment with just bowtie two installed and the same problem occurs please see code below. How can I solve this issue?

Thank you for your time and help.

Sincerely,

David

(base) mab@DESKTOP-6BMVSG8:/mnt/c/Users/bradshawd$ conda create -n bowtie2 bowt ie2 -c bioconda

Collecting package metadata (current_repodata.json): done Solving environment: done

Package Plan

environment location: /home/mab/miniconda3/envs/bowtie2

added / updated specs:

• bowtie2

The following NEW packages will be INSTALLED:

_libgcc_mutex conda-forge/linux-64::_libgcc_mutex-0.1-conda_forge _openmp_mutex conda-forge/linux-64::_openmp_mutex-4.5-0_gnu bowtie2 bioconda/linux-64::bowtie2-2.4.1-py37h4ef193e_2 ca-certificates conda-forge/linux-64::ca-certificates-2020.6.20-hecda079_0 certifi conda-forge/linux-64::certifi-2020.6.20-py37hc8dfbb8_0 ld_impl_linux-64 conda-forge/linux-64::ld_impl_linux-64-2.34-h53a641e_5 libffi conda-forge/linux-64::libffi-3.2.1-he1b5a44_1007 libgcc-ng conda-forge/linux-64::libgcc-ng-9.2.0-h24d8f2e_2 libgomp conda-forge/linux-64::libgomp-9.2.0-h24d8f2e_2 libstdcxx-ng conda-forge/linux-64::libstdcxx-ng-9.2.0-hdf63c60_2 ncurses conda-forge/linux-64::ncurses-6.1-hf484d3e_1002 openssl conda-forge/linux-64::openssl-1.1.1g-h516909a_0 perl conda-forge/linux-64::perl-5.26.2-h516909a_1006 pip conda-forge/noarch::pip-20.1.1-py_1 python conda-forge/linux-64::python-3.7.6-cpython_h8356626_6 python_abi conda-forge/linux-64::python_abi-3.7-1_cp37m readline conda-forge/linux-64::readline-8.0-hf8c457e_0 setuptools conda-forge/linux-64::setuptools-47.3.1-py37hc8dfbb8_0 sqlite conda-forge/linux-64::sqlite-3.30.1-hcee41ef_0 tbb conda-forge/linux-64::tbb-2020.1-hc9558a2_0 tk conda-forge/linux-64::tk-8.6.10-hed695b0_0 wheel conda-forge/noarch::wheel-0.34.2-py_1 xz conda-forge/linux-64::xz-5.2.5-h516909a_0 zlib conda-forge/linux-64::zlib-1.2.11-h516909a_1006

Proceed ([y]/n)? y

Preparing transaction: done Verifying transaction: done Executing transaction: done

To activate this environment, use

$ conda activate bowtie2

To deactivate an active environment, use

 $ conda deactivate

$(base) mab@DESKTOP-6BMVSG8:/mnt/c/Users/bradshawd$ conda activate bowtie2

$(bowtie2) mab@DESKTOP-6BMVSG8:/mnt/c/Users/bradshawd$ bowtie2 --version

/home/mab/miniconda3/envs/bowtie2/bin/bowtie2-align-s version 64-bit Built on Sat Jun 6 20:17:22 UTC 2020 Compiler: gcc version 7.5.0 (crosstool-NG 1.24.0.123_1667d2b) Options: -O3 -msse2 -funroll-loops -g3 -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/mab/miniconda3/envs/bowtie2/include -fdebug-prefix-map=/opt/conda/conda-bld/bowtie2_1591474367590/work=/usr/local/src/conda/bowtie2-2.4.1 -fdebug-prefix-map=/home/mab/miniconda3/envs/bowtie2=/usr/local/src/conda-prefix -DPOPCNT_CAPABILITY -DWITH_TBB -std=c++11 -DNO_SPINLOCK -DWITH_QUEUELOCK=1 Sizeof {int, long, long long, void*, size_t, off_t}: {4, 8, 8, 8, 8, 8}

[rpetit3]

Came to report the same. Ariba is affected as well.

[junaruga]

I reported a similar issue #294 in the past.

[BenLangmead]

I am guessing this happens because the conda build process does not include the VERSION file, which the Makefile attempts to cat into the BOWTIE2_VERSION macro, but I will defer to @ch4rr0

[cblume]

Can confirm that this only happens in the current Bioconda version of bowtie2.

[djbradshaw2]

Thanks all for the responses, so this is more of a conda issue than anything with bowtie2 itself per what @cblume and @BenLangmead have said? Thank you @rpetit3 for opening the issue over at bioconda and sorry @junaruga for not realizing yours was a similar issue.

[rpetit3]

Would making VERSION able to be set at the command line (e.g. make VERSION=2.4.1) be ok?

It seems weird to let the VERSION be set by the user, but thinking for the conda build (build.sh) it could be something like:

LDFLAGS=""
CXXFLAGS="$CXXFLAGS -std=c++11"
mv VERSION VERSION.txt
make CXX=$CXX CPP=$CXX CC=$CC LDLIBS="-L$PREFIX/lib -lz -ltbb -ltbbmalloc -lpthread" VERSION=`cat VERSION.txt`

It looks like the change was made because the VERSION file caused issues with C++20.

Just tossing this out there. If OK, I'm happy to submit a PR with the changes in the Makefile.

[jmarshall]

This is the same problem as arq5x/bedtools2#830 and bowtie2 itself will soon experience it too. The Conda build has just been first to use an affected compiler, and then has broken ‑‑version by putting in an incomplete fix (mv VERSION VERSION.txt) and not noticing the cat: VERSION: No such file or directory error messages in their build logs.

The root problem is that bowtie has a file named VERSION in a directory that -I . causes to be searched, and on case-insensitive file systems (macOS) that file is picked up by #include <version>, which occurs as part of the standard library on recent compilers.

The best way to fix it is to rename VERSION, to BOWTIE2_VERSION or VERSION.txt say, and update the references to the file in CMakeLists.txt, Makefile (×3), and doc/release.txt accordingly. Then neither Conda nor anyone else will need to do anything special to work around this problem.

[djbradshaw2]

@rpetit3 and @jmarshall thanks for the suggestions for the potential fixes. I am on a Windows Subsystem for Linux 2, so will have to figure out where those files are @jmarshall, but will give it a try. If it works for someone else please let us know, I am gonna be a bit slow with it, newbie and all.

[djbradshaw2]

It seems like this is fixed in latest update of humann3 so it does not break things. I have not had a chance to test this out yet but seems like @rpetit3 used @jmarshall 's fix and it worked. So closing this for now, thank you all for the help!

[rpetit3]

Hello @djbradshaw2

Has there been any updates regarding this issue?

Thank you!

[djbradshaw2]

@rpetit3 Honestly I have not been pursuing it, since it was fixed in the tool I was using with a work around. I thought that you and @jmarshall had a good temporary fix so I closed the issue here. I thought you were pursuing it further in the Rename VERSION to BOWTIE2_VERSION #302 thread. If you are still experiencing issues in the tools you are using I can reopen thread, if you'd like.

[rpetit3]

@djbradshaw2 Thank you for the follow up! If you could reopen that would be great.

@BenLangmead @ch4rr0 Are there plans to pursue this, or should I submit a patch on the Bioconda side of things? Thank you!

[ch4rr0]

Yes, I’ll look into a solution for this issue today.

[ch4rr0]

@djbradshaw2 — I went ahead and removed all -I . arguments to the compiler. Let me know if this works for your setup.

[rpetit3]

Hi @ch4rr0 !

This issue is related to the BioConda release, and dealing with the VERSION file.

Here's a PR with my suggested revision: https://github.com/BenLangmead/bowtie2/pull/302

Link to issue on BioConda: https://github.com/bioconda/bioconda-recipes/issues/22836

Thank you very much for following up!

[ch4rr0]

I went ahead and merged the PR.

[jmarshall]

Confirmed that removing -I . makes compilation succeed on macOS with an affected compiler where it did not work before. As you (currently) have no .cpp source files in subdirectories, you don't need -I. anyway. But it's a good idea to apply the renaming too, as you've done, in case it comes back again.

For bioconda to benefit, they'd need to apply a similar patch or (ideally) they will pick this up from an upcoming bowtie2 release, which is hopefully not too far off…?

[jmarshall]

Note that with that PR merged, _BOWTIE2VERSION identifies the current version as 2.4.2, but presumably no such version has yet been released.