Closed pdimens closed 2 years ago
sounds like you are using a non-standard CPU (*meaning, not x64) and need to recompile, what does uname -a
report on that machine?
Thanks for the prompt reply :) I'm pretty sure it's a common x64 Intel Xeon system. Here is the information requested
$ uname -a
Linux karen 5.10.70-1-MANJARO #1 SMP PREEMPT Thu Sep 30 15:29:01 UTC 2021 x86_64 GNU/Linux
That's strange, I've been building Linux binaries this way for many years and almost never run into problems like this. The work-around is to recompile on that machine. Do pre-compiled binaries for other github software run ok?
Yep, I use them all the time. I can try to manually recompile and see what happens. I'll report back.
running make
, I get a LOT of errors that all pretty much say
‘typedef unsigned char byte’
This is with gcc 11.1.0
here's the tail of the long list of errors
In file included from /usr/include/c++/11.1.0/bits/stl_algobase.h:61,
from /usr/include/c++/11.1.0/bits/char_traits.h:39,
from /usr/include/c++/11.1.0/string:40,
from myutils.h:22,
from muscle.h:21,
from addconfseq.cpp:1:
/usr/include/c++/11.1.0/bits/cpp_type_traits.h:404:30: note: candidates are: ‘enum class std::byte’
404 | enum class byte : unsigned char;
| ^~~~
In file included from muscle.h:21,
from addconfseq.cpp:1:
myutils.h:77:23: note: ‘typedef unsigned char byte’
77 | typedef unsigned char byte;
| ^~~~
In file included from addconfseq.cpp:1:
muscle.h:111:48: error: reference to ‘byte’ is ambiguous
111 | void CalcBwdFlat(const byte *X, uint LX, const byte *Y, uint LY, float *Flat);
| ^~~~
In file included from /usr/include/c++/11.1.0/bits/stl_algobase.h:61,
from /usr/include/c++/11.1.0/bits/char_traits.h:39,
from /usr/include/c++/11.1.0/string:40,
from myutils.h:22,
from muscle.h:21,
from addconfseq.cpp:1:
/usr/include/c++/11.1.0/bits/cpp_type_traits.h:404:30: note: candidates are: ‘enum class std::byte’
404 | enum class byte : unsigned char;
| ^~~~
In file included from muscle.h:21,
from addconfseq.cpp:1:
myutils.h:77:23: note: ‘typedef unsigned char byte’
77 | typedef unsigned char byte;
| ^~~~
make: *** [Makefile:183: o/addconfseq.o] Error 1
Let me know how else I can assist troubleshooting or debugging this.
Fixing the compile errors should be straightforward, I need to get gcc-11 to resolve that one, it does seem a lot of people are using v11; I was targeting gcc v9 because it's the default in ubuntu 20.04. It's the binary incompatibility that's baffling. Can you verify the checksum:
wget https://github.com/rcedgar/muscle/releases/download/v5.0.1428/muscle_v5.0.1428_linux
md5sum muscle_v5.0.1428_linux
8c81b3c4d258ae92acb02a6a6327a1e6 muscle_v5.0.1428_linux
./muscle_v5.0.1428_linux --version
muscle 5.0.1428_linux64
If you have the same file I do I'm not sure how to trouble-shoot. Can you give me an ssh account to a machine where the problem occurs?
The binary I downloaded was
https://github.com/rcedgar/muscle/blob/main/binaries/muscle
and the checksum is different
➜ md5sum ./muscle
bd513d48aade9804b6013f8615785a50 muscle
however, I tried the link in your code above and that seemed to work fine :thinking:
I believe this one was user error on my part, incorrectly pulling the binary from the binary folder. However, we did uncover a failure to compile with gcc 11. What is the muscle
file in the binaries/
directory?
Ok, well some sanity is restored. The binaries/ version should also work, but it is older. I'm a github novice and still learning how to use the site in the way people expect. Compatibility with gcc-11 is in progress in #10, I'm not sure how to tackle this one because targeting any given gcc version is liable to break compatibility with other versions. I just don't have the bandwidth to learn as much as I would like about modern open-source development, I also have to do some science...
That's fair. I would recommend to link the binaries from the tagged release into the README text to future-proof this happening again because there is certainly disparity between the two!
Hello! I downloaded the latest linux binary but cannot get it to run. The steps I used are as follows:
The result is the same using the absolute path to the binary.