linux binary will not run

[pdimens]

Hello! I downloaded the latest linux binary but cannot get it to run. The steps I used are as follows:

chmod +x muscle
./muscle
zsh: exec format error:

The result is the same using the absolute path to the binary.

[rcedgar]

sounds like you are using a non-standard CPU (*meaning, not x64) and need to recompile, what does uname -a report on that machine?

[pdimens]

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

[rcedgar]

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?

[pdimens]

Yep, I use them all the time. I can try to manually recompile and see what happens. I'll report back.

[pdimens]

running make, I get a LOT of errors that all pretty much say

‘typedef unsigned char byte’

This is with gcc 11.1.0

[pdimens]

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

[pdimens]

Let me know how else I can assist troubleshooting or debugging this.

[rcedgar]

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?

[pdimens]

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?

[rcedgar]

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...

[pdimens]

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!