Newer kernels/libc use this in preference to `stat`/`fstat`.

Reported-by: Lucas Nussbaum <lucas@debian.org>

Debian: #1002186 “rumur: FTBFS”
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002186

This aids reproducible builds, which we have gradually been progressing towards.

At this point it seems unlikely the Flex bug¹ that prevents using
`%option noline` will ever be fixed. So lets just use the work around for it.

¹ https://github.com/westes/flex/issues/268

See also https://cirrus-ci.org/guide/macOS/.

Github seems to now require authentication for release asset links, so CI was
when attempting to fetch this.

fix build failures when using shared libraries

In the latest release, this caused link problems:

  ld: error: undefined hidden symbol: rumur::parse(std::__1::basic_istream<char,
    std::__1::char_traits<char> >&)
  >>> referenced by main.cc
  >>>               murphi2c/CMakeFiles/murphi2c.dir/src/main.cc.o:(main)

  ld: error: undefined hidden symbol: rumur::resolve_symbols(rumur::Model&)
  >>> referenced by main.cc
  >>>               murphi2c/CMakeFiles/murphi2c.dir/src/main.cc.o:(main)

  ld: error: undefined hidden symbol: rumur::validate(rumur::Node const&)
  >>> referenced by main.cc
  >>>               murphi2c/CMakeFiles/murphi2c.dir/src/main.cc.o:(main)

  ld: error: undefined hidden symbol: rumur::sanitise_rule_names(rumur::Node&)
  >>> referenced by main.cc
  >>>               murphi2c/CMakeFiles/murphi2c.dir/src/main.cc.o:(main)

Github: related to #220 “2021.08.28: Fails to link: error: undefined hidden…”

When building shared libraries as opposed to static libraries, a variety of
build and link errors would be encountered. This all stems from commit
53344ec8. The addition of `hidden` visibility in
some circumstances appears flat out wrong, in that it contradicts both GCC
advice¹ as well as other guides to symbol visibility.²

The corrected solution applied in this commit is to attach *no* visibility when
compiling something that links against librumur, letting the default (possibly
set through `-fvisibility=…`) take effect.

¹ https://gcc.gnu.org/wiki/Visibility
² https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html

Github: fixes #220 “2021.08.28: Fails to link: error: undefined hidden…”

It has not been possible for this function to return null for sometime. This
behavior was introduced to simplify type discrimination logic that was regularly
having to do is-null checks and hard code that this meant a numeric literal.

Migration away from Travis CI to Cirrus CI was completed in commit
bfefe96b.

This job has been broken for some time – even prior to the Travis shutdown – due
to environment problems. When working, it also had not surfaced any bugs in a
long time. While fuzzing support is there and it works, AFL is no longer a state
of the art fuzzer and fuzzing from scratch is no longer particularly effective.
A better approach to this now would be to use a more advanced fuzzer and do
continuous (or at least resuming) fuzzing.

This completes the migration away from Travis CI.

I think we have to accept it is no longer practical to test with GCC multilib in
CI.

With testing of Clang on macOS in Cirrus, we probably have sufficient coverage.

With Travis defunct, it does not look like we have a reasonable option for
testing these anymore.

With testing of GCC 4.9 and then GCC 8, 9 and 10 in Cirrus I think we have
sufficient coverage.

backport to Python 3.4 and add GCC 4.9 testing

Testing 4.9 in Cirrus is the best we can currently achieve to validate that we
work with GCC 4.

This started as an attempt to add testing on GCC 4.7. However, the GCC 4.7
Docker image is based on Debian Wheezy which is well out of support. Just
getting functioning apt repositories is challenging. Once that is bootstrapped,
it becomes apparent that the available versions of Bison, CMake and Python are
too old. We have already bypassed CMake (downloading a static binary from
Kitware) and can probably bypass Bison, but Python is on 3.2. Compiling Python
3.4 in CI is not reasonable and further backporting the Rumur Python scripts to
work with Python 3.2 is a bridge too far. The GCC 4.8 image is similarly
impoverished.

So I think, out of practicality, GCC 4.9 has to become the new supported
baseline. 4.9.0 was released in 2014, so hopefully it is not too much of a
burden for users. The GCC 4.9 image is on Debian Jessie which is functional, for
now.

When migrating away from Travis CI that is now defunct, it seems it is hard to
get a working Python 3.6 on a system that also runs GCC 4 series. Instead of
dropping GCC 4 compatibility, it seems more friendly to drop our required
minimum Python version.

When migrating away from Travis CI that is now defunct, it seems it is hard to
get a working Python 3.6 on a system that also runs GCC 4 series. Instead of
dropping GCC 4 compatibility, it seems more friendly to drop our required
minimum Python version.

When migrating away from Travis CI that is now defunct, it seems it is hard to
get a working Python 3.6 on a system that also runs GCC 4 series. Instead of
dropping GCC 4 compatibility, it seems more friendly to drop our required
minimum Python version.

When migrating away from Travis CI that is now defunct, it seems it is hard to
get a working Python 3.6 on a system that also runs GCC 4 series. Instead of
dropping GCC 4 compatibility, it seems more friendly to drop our required
minimum Python version.

GCC 8 Cirrus setup

setup Linux GCC 9 testing

move FreeBSD testing to 12.2

finish enabling GCC 10 in Cirrus

The FreeBSD 12.1 snap seems no longer bootable (and has not been so for some
time). This is perhaps unsurprising as 12.1 was EOLed in January 2021.¹

¹ https://www.freebsd.org/security/unsupported/

As of the previous commit, the Cirrus GCC 10 job should completely subsume
these.