ERROR: Hapo-G didn't finish successfully, exit code: 127

[SAMtoBAM]

ERROR: Hapo-G didn't finish successfully, exit code: 127

[bistace]

Hello and thank you for using Hapo-G.

This is the first time we encounter this error but I may have an idea of what is causing it.
Could you please confirm me that you built Hapo-G using the build.sh bash script? If you did, could you please download the latest commit, execute the script again and test if my changes worked?

[SAMtoBAM]

Yes so I have followed your installation steps and built it with the bash script
I downloaded the latest version and still the same problem unfortunately

[bistace]

Did you remove everything and build it again with the build.sh script?

[SAMtoBAM]

Sure did

[bistace]

It seems there is a problem with the build but I don't really know what went wrong. Could you please try to do
export LD_LIBRARY_PATH=/path/to/hapog/root/src/htslib/lib:$LD_LIBRARY_PATH and launch your command again?

Don't forget to replace /path/to/hapog/root by the correct folder on your system.

[SAMtoBAM]

I tried that but no luck.
In my build there is no root directory inside hapog.
In fact, the path is "/home/samuel/hapog/src/htslib/src/htslib/lib"

and that seems to be the problem
i did:
export LD_LIBRARY_PATH=/home/samuel/hapog/src/htslib/src/htslib/lib:$LD_LIBRARY_PATH
and it got past this issue! and all seems to be working well

Thanks for the help
I hope this tool will become very useful as phased genomes become more common!

[jmarshall]

The problem here is that @SAMtoBAM has samtools and htslib 1.10 or later installed, which installs libhts.so.3.

Meanwhile Hapo-G's build.sh script explicitly pulls down htslib-1.9, builds hapog against it, and explicitly links against that htslib version's libhts.so.2 (effectively).

However @SAMtoBAM's LD_LIBRARY_PATH only has the libhts.so.3 version on it, hence the error — until this is worked around by adding the appropriate hapog build directory to $LD_LIBRARY_PATH so that both libhts.so.2 and libhts.so.3 are available.

The best way to fix this would be to rework the build script so that it was easier to build hapog against an externally-supplied htslib that you might already have installed. This would be necessary for adding this package to bioconda, for example.

An alternative (and not quite so good) way to solve this problem would be to carry on building your own copy of htslib 1.9 but link against the resulting libhts.a rather than the shared library, so that the hapog executable is more self-contained.

[bistace]

Hi John,

you're totally right, I will try to modify the cmake build instructions to build against an existing version of htslib as it seems to be the best solution.

[bistace]

Hi,

we've reworked the CMake code to account for multiple situations:

• the user can now specify the path to an existing htslib installation with the -l flag of the build.sh script. If no valid htslib files are found, the building step is stopped.
• if the -l flag is not given, cmake will attempt to find an existing installation on the system
• if cmake doesn't find any existing installation, cmake will pull htslib from github and compile it

I hope that this will help avoiding errors like this in the future and thank you all for your help.