RFC: GitHub actions for Windows, macOS, and Linux

[lucyllewy]

While working on Travis, I found that I couldn't test due to having depleted my free-tier credits and couldn't find any way of continuing without paying for the monthly subscription. I have therefore written this example GitHub Actions workflow that builds pull requests for Windows, macOS, and Linux as a proof of concept for you to consider.

Feedback welcome :-)

[lucyllewy]

This includes the change in #434 to get Windows builds running. I'll edit and push to drop that change for now based on discussion there.

The change to vendor win32.mak is not included anymore.

[lucyllewy]

ok, good to go again now.

[lucyllewy]

I'm not sure what I'm doing wrong with the macOS build, but the Windows builds are succeeding now, and the Linux builds are also working. An example of the macOS build failure is at https://github.com/diddledani/hyperion/runs/4587231341

[wrljet]

I don't understand how to see the actual log output. It just shows Error when the build is expanded.

[lucyllewy]

odd, it should load the log when you expand the item in the right hand pane. In case GitHub is having an issue showing it, I've copied the log to https://paste.ubuntu.com/p/KC32m7SsZD/

This is how the screen looks with it expanded here (for reference):

[wrljet]

Dani, a few things...

For packages, you'll want to include these in your brew install: autoconf automake libtool cmake gsed

cmake is used to build the extpkgs, which I've mentioned below.

Then you'll want to do this or something equivalent, so configure and building will find the correct libtool and ltdl library. (HomeBrew puts stuff in odd place)

export CFLAGS="$CFLAGS -I$(find $(brew --cellar libtool) -type d -name "include" | sort -n | tail -n 1)"
export LDFLAGS="$LDFLAGS -L$(find $(brew --cellar libtool) -type d -name "lib" | sort -n | tail -n 1)"

Later in the building you'll find that the canned extpkgs libraries in the Hercules repo won't be compatible with MacOS and its tools. So you'll want to build those before running configure. If you want help on how to do that, just ask.

For configure you'll want some more options:

./configure \
    --enable-optimization="-g -g3 -ggdb3 -O3" \
    --enable-extpkgs=<where you built extpkgs> \
    --enable-regina-rexx \
    --disable-getoptwrapper

Bill

[lucyllewy]

Thanks for the help :-) Successful builds on macOS 10.15, but macOS 11 failed with a segfault in the testsuite.

https://github.com/diddledani/hyperion/actions/runs/1604166836

Probably due to the slew of linker warnings:

ld: warning: object file (/Users/runner/work/hyperion/hyperion/extpkgs/lib/libcrypto64.a(crypto_version.c.o)) was built for newer macOS version (11.6) than being linked (11.0)
ld: warning: object file (/Users/runner/work/hyperion/hyperion/extpkgs/lib/libdecNumber64.a(decnumber_version.c.o)) was built for newer macOS version (11.6) than being linked (11.0)
ld: warning: object file (/Users/runner/work/hyperion/hyperion/extpkgs/lib/libSoftFloat64.a(softfloat_version.c.o)) was built for newer macOS version (11.6) than being linked (11.0)
ld: warning: object file (/Users/runner/work/hyperion/hyperion/extpkgs/lib/libtelnet64.a(telnet_version.c.o)) was built for newer macOS version (11.6) than being linked (11.0)
... # and more similar

[wrljet]

I only see that red Error:

[lucyllewy]

I used @Fish-Git 's script in https://github.com/SDL-Hercules-390/gists to fetch and compile the extpkgs so perhaps there's some slightly different settings used there than via the ./configure script generated for hercules itself?

[wrljet]

The commands related to extpkgs look fine in your yml.

[wrljet]

Dani,

You need to use those lines I suggested, to get the correct version of libltdl header and library from HomeBrew. Otherwise you're using the wrong incompatible version from Xcode.

export CFLAGS="$CFLAGS -I$(find $(brew --cellar libtool) -type d -name "include" | sort -n | tail -n 1)"
export LDFLAGS="$LDFLAGS -L$(find $(brew --cellar libtool) -type d -name "lib" | sort -n | tail -n 1)"

The /usr/local/include/libltdl you put in configure is the wrong package.

Bill

[lucyllewy]

the /usr/local/include/libltdl is the homebrew version. This will be /opt/homebrew/include/libltdl on M1 macs (which I tested this on). By default there is no such directory in macOS at /usr/local/include/libltdl. (note the local part indicating non-os-provided files)

[wrljet]

Dani,

the /usr/local/include/libltdl is the homebrew version. This will be /opt/homebrew/include/libltdl on M1 macs (which I tested this on). By default there is no such directory in macOS at /usr/local/include/libltdl. (note the local part indicating non-os-provided files)

That depends on how things were installed. Assuming you've got the correct ltdl.h, from where are you getting the shared library?

On my M1 hardware, for example, libltdl.* is in /opt/homebrew/Cellar/libtool/2.4.6_4/lib and there nothing in /usr/local....

Bill

[lucyllewy]

Good point on potentially being elsewhere. I've amended it to use your preferred command to build the CFLAGS and LDFLAGS. I was relying on the libs being in /usr/local/lib where on my M1 they're in /opt/homebrew/lib. They can be not-there if homebrew is configured to not symlink them from their cellar.

[wrljet]

That may be related to if they were installed with sudo, or not.

FWIW, a number of Hercules users have used my Hercules-Helper on MacOS, and this scheme seems to work everywhere I've encountered so far, on M1 and x86_64.

On x86_64, my test suite includes High Sierra (10.13.6), Mojave (10.14.6), Catalina (10.15.7), Big Sur (11.13.1), and Monterey (12). On Big Sur I test with both HomeBrew and MacPorts.

On Apple M1 silicon I only have Big Sur (11.13.1).

Bill

[wrljet]

Dani,

How come I get a notification from GitHub about changes to your .yml file, but when I browse around in the SDL-Hercules-390 repo, I don't find the file anywhere?

And why can't I see the actual build log, and just that Error?

Bill

[lucyllewy]

I suspect you're being notified of changes via the yaml being part of this PR.

As to the build log, it might be specific to your browser and any extensions you have? Worth trying to see if there's any browser logs in the "browser console" which in Chrome and Firefox is accessed with the F12 key, and Safari with cmd+option+c.

[wrljet]

I guess that's possible -- Firefox seems to work correctly on fewer and fewer websites recently. But this is the first trouble I've encountered with GitHub.

So I just now tried it on MSFT Edge and the log appears as expected.

(insert cussing here)

[wrljet]

I updated a MacOS VM to the latest Monterey, and also get a segmentation fault running the tests.

11:07:04 HHC01603I * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
11:07:04 HHC01603I *
11:07:04 HHC01603I * Start of test file ../tests/CCW-ILS.tst date in /Users/bill/herctest/hyperion/tests
11:07:04 HHC01603I *
11:07:04 HHC01603I *Testcase CCW-ILS (CCW Incorrect Length Suppression)
11:07:04 HHC00101I Thread id 000070000b357000, prio 2, name 'Processor CP00' ended
11:07:04 HHC01603I mainsize    1
11:07:04 HHC17003I MAIN     storage is 1M (mainsize); storage is not locked
11:07:04 HHC01603I numcpu      1
11:07:04 HHC02204I NUMCPU         set to 1
11:07:04 HHC01603I sysclear
11:07:04 HHC00100I Thread id 000070000b866000, prio 2, name 'Processor CP00' started
11:07:04 HHC00811I Processor CP00: architecture mode z/Arch
11:07:04 HHC00101I Thread id 000070000b763000, prio 2, name 'Processor CP01' ended

    +++ OOPS! +++

Hercules has crashed! (Segmentation fault: 11)

[wrljet]

Did a bit more on Monterey 12.1. It crashes when built with Clang 13 or 12, but works with Clang 11.

Bill

[Fish-Git]

It crashes when built with Clang 13 or 12, but works with Clang 11.

Insert cussing here?  :)

[wrljet]

It crashes when built with Clang 13 or 12, but works with Clang 11.

Insert cussing here? :)

Ordinarily yes, of course. But sometimes things are just so discouraging, cussing doesn't help. This is one of those times. :(

[wrljet]

It crashes when built with Clang 13 or 12, but works with Clang 11.

Insert cussing here? :)

Fish,

Good news ... it seems to be function inlining related. :(

Bill

[Fish-Git]

Good news ... it seems to be function inlining related. :(

GOOD news?!

(FRICK!!)

Why can't gcc/clang seem to do inlining correctly?!   (sigh!)

  :(

[wrljet]

Fish, I think we can safely ignore and close this PR. The actions rig has been revamped on GitHub since this came along.

FWIW, I have in-the-works new GitHub actions to do builds on every commit. Linux and macOS.

Bill

[wrljet]

Since this entire apparatus is being replaced, I'm going ahead and closing this PR w/o merging.