Trying to compile and link on MacOs Sonoma

[TonyInnes]

Hi,

I am trying to compile Hyperon on MacOs Sonoma. 14.1.1

After downloading the build I run a ./configure from directory hyperon-master. All goes well. Next I run a make clean. next is a make. This fails with the following;

Making all in .
  CC       cckdcdsk.o
  CC       hsys.lo
  CCLD     libhercs.la
ld: multiple errors: archive member '/' not a mach-o file in '/Users/tony/Downloads/hyperion-master/telnet/lib/libtelnet64.a'; archive member '/' not a mach-o file in '/Users/tony/Downloads/hyperion-master/decNumber/lib/libdecNumber64.a'; archive member '/' not a mach-o file in '/Users/tony/Downloads/hyperion-master/crypto/lib/libcrypto64.a'; archive member '/' not a mach-o file in '/Users/tony/Downloads/hyperion-master/SoftFloat/lib/libSoftFloat64.a'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libhercs.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

What is all this mach-o all about. Any help much appreciated.

Regards Tony

[atncsj6h]

/Users/tony/Downloads/hyperion-master/telnet/lib/libtelnet64.a decnumber, softfloat, crypto

are windows only library so are not mach-o objects.

To build hercules for linux/bsd like systems and Apple use the "Hercules-Helper" from Bill Lewis:

• https://github.com/wrljet/hercules-helper

[wrljet]

Tony,

There are instructions on how to do this by hand here.

But it's a bit complicated on macOS, so Hercules-Helper will probably be easier for you.

Bill

[rbanffy]

I am having an entertaining time myself (building a Docker image to serve as a base for other images) on multiple platforms and the instructions are, indeed, a bit convoluted and, it seems, sometimes not quite correct (doing so on a Linux s390x VM under qemu). I am getting there and, when it's done, the Dockerfile will contain instructions to build everything from source on anything Unix-like enough.

[Fish-Git]

Not a bug. User simply failed to follow documented build instructions. Closing.

(admittedly, we could probably so better in this area. Perhaps by doing a better job at promoting use of Hercules-Helper??)

[rbanffy]

I really don't like the Hercules-Helper route. It papers over real issues with the build system and tooling. I didn't have the time to look into why I ended up with some amd64 binaries when building on non-amd64 architectures, but it sure looks like a problem in the configuration.

I'll have some time to try that on real non-amd64 metal later this week, so the iteration time might end up a little bit better.

[wrljet]

If you run Hercules-Helper once, it will create a script with just what it did. That, with very little editing will be the exact steps to recreate it all (with all its institutional knowledge in there).

Bill

[rbanffy]

Do we continually test Hercules-Helper on multiple OSs and architectures?

I still found it odd that a very default ./autogen.sh && ./configure && make ended up with amd64 binaries in the non-core libraries, even when running on a non-amd64 platform - I did a little digging, but couldn't find where the architecture mismatch was introduced.

[wrljet]

Ricardo,

"continually" and automatically, no. But it does get a lot of exercise from the community and myself.

I have some continuous building with GitHub Actions on my own fork, which builds for the more popular CPU/OS combinations. But that is not committed yet here while some licensing questions are being answered.

With the very simple build commands you mentioned, it will be using pre-compiled extpkgs, which only exist for x86-64 Linux.