Please consider making dependencies able to be dynamically linked
Currently, when you have dynamic libraries in your LD_LIBRARY_PATH and try to build StringTie you will get an error like below, because the Makefile of HTSlib picks them up and doesn't build the static libraries, but your Makefile still expects them and in a fixed location:
/mnt/software/easybuild/20.04/software/binutils/2.37-GCCcore-11.2.0/bin/ld.gold: error: cannot open ./htslib/xlibs/lib/liblzma.a: No such file or directory
cram/cram_io.c:1291: error: undefined reference to 'lzma_stream_buffer_bound'
cram/cram_io.c:1297: error: undefined reference to 'lzma_easy_buffer_encode'
cram/cram_io.c:1313: error: undefined reference to 'lzma_easy_decoder_memusage'
cram/cram_io.c:1313: error: undefined reference to 'lzma_stream_decoder'
cram/cram_io.c:1331: error: undefined reference to 'lzma_code'
cram/cram_io.c:1344: error: undefined reference to 'lzma_code'
cram/cram_io.c:1355: error: undefined reference to 'lzma_end'
cram/cram_io.c:1360: error: undefined reference to 'lzma_end'
cram/cram_io.c:1355: error: undefined reference to 'lzma_end'
collect2: error: ld returned 1 exit status
make: *** [Makefile:179: stringtie] Error 1
I created a patch for my case here: https://github.com/easybuilders/easybuild-easyconfigs/pull/15261. It would be better to solve this in this repository.
Thank you for the suggestion, I've been considering that when I switched to htslib which pulled in a lot of these additional dependencies that can get very complex. There were a few arguments for the path I chose instead, with my own copy/branch of htslib, plus local copies of those dependencies needed to build htslib:
- allowing custom code changes to htslib that the official htslib API does not support yet
- creating a semi-static, quasi-portable binary which can be used on another linux system that might not have those dynamic libraries installed
- being able to build StringTie from source on systems that do not have lzma and other development packages installed (and might not be able to install them)
The first point above ended up not being the case so far (it was when I initially started porting stringtie to htslib, but meanwhile they added the API I needed). The other two points could likely be covered by using a better (real) build system, instead of the duct-tape makefile solutions I'm using -- admittedly I never got around to learn how to use autoconf or CMake properly.. and haven't been convinced they are worth the trouble.
@gpertea Thank you very much for the detailed explanation! So it will stay this way in the foreseeable future. For others running into issues or interested there are ways to work around this in the linked pull request above.