11-11-2019, 06:47 PM
Okay, this is going to be a bit of a long shot, because I'm really not an expert on how all this stuff works, and barely even understand the nuts and bolts of how libraries get organized and used under Linux. However, I also hit the mysterious "bus error" problem myself, and in my case, I found a way to fix it that worked, so I figure I might as well share.
For me, this happened with `zpaq`, which is a very small high-performance archive compressor that I use a lot. At first, I had no idea what to try, but then when attempting to build from source, I ran across this in the readme:
That was, as far as I can tell, it. When I recompiled using this flag, everything was fine. I guess the maintainer of zpaq (and lrzip, a similar tool that produced a similar error when I tried it) overlooked this when they committed their build to the repos?
In any case, if building from source is an option for you, it seems like this problem may sometimes be caused by incorrect runtime optimizations being enabled, and can be corrected by disabling them.
Good luck!
For me, this happened with `zpaq`, which is a very small high-performance archive compressor that I use a lot. At first, I had no idea what to try, but then when attempting to build from source, I ran across this in the readme:
Code:
-DNOJIT = turn off run time optimization of ZPAQL to 32 or 64 bit x86
in libzpaq. Use this for a non-x86 processor, or old
processors not supporting SSE2 (mostly before 2001).
That was, as far as I can tell, it. When I recompiled using this flag, everything was fine. I guess the maintainer of zpaq (and lrzip, a similar tool that produced a similar error when I tried it) overlooked this when they committed their build to the repos?
In any case, if building from source is an option for you, it seems like this problem may sometimes be caused by incorrect runtime optimizations being enabled, and can be corrected by disabling them.
Good luck!