Update to Gradle 8; resuscitate CI #238

Without this change, compilation on newer versions of GCC fails: cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU The [GCC 8 ARM changes] note that “`-mfpu=auto` is now the default setting unless the compiler has been configured with an explicit `--with-fpu` option.” We were setting `-mfpu` to something other than `auto`, but one possible interpretation of that sentence is “the value of this option is now ignored unless you pass `--with-fpu`”. And of course, didn't, so on architectures where an FPU is optional (ARMv6 and ARMv7), we were being pushed onto a compile path that assumed the absence. A quick search uncovers a few other people dealing with this. Some distro developers discussing [how to handle the switch] refer to GCC 8, but the general consensus seems to be that the breaking change was introduced [with GCC 11] in Debian/Ubuntu. The GitHub Actions runners for Ubuntu 18.04 are now dead, but the last [installed software list] indicates that they included GCC v7.5.0, v9.4.0, and v10.3.0; presumably v7.5.0 was the default, which is why we didn't run into this before now. (The logs and artifacts from the last successful CI build are long expired.) I expect that this breaks compilation on GCC <v8. [GCC 8 ARM changes]: https://gcc.gnu.org/gcc-8/changes.html#arm [installed software list]: https://github.com/actions/runner-images/blob/425daf97b4452130f0065e4fc58b5c8b34ab1941/images/linux/Ubuntu1804-Readme.md [how to handle the switch]: https://gcc.gnu.org/pipermail/gcc/2021-September/237363.html [with GCC 11]: https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/1939379#yui_3_10_3_1_1692749691943_147

The project doesn't actually use any headers from the JavaVM framework, so we don't need to link against it.

...rather than accepting whatever default we get for the x86_64 arch. I've chosen 10.7 because that's the lowest requirement I can find for a Java 8 JDK. No sense in building natives for anything older if there's no way to run them there.

GitHub will continue to merrily deprecate and remove old runner environments, as is their prerogative. However, the simplest way to produce a library with a low minimum glibc version requirement is to build in an environment having an old glibc. Not only does Ubuntu 18.04 have a fairly old glibc (v2.27), but the symbol versions our library links against require only glibc v2.7 (on x86_64; somewhat higher for some of the other architectures). Having previously fixed cross-compilation compatibility with GCC 8, we are no longer able to build with GCC 7-based compilers. Thankfully, Ubuntu did package GCC 8 on 18.04; it's just not the default.

No need to apply some of plugins outside of the plugins block.

The archive name is automatically derived from the `archivesBaseName` and the `version`. And we don't have any duplicate archive contents, so we don't benefit from setting a strategy to cope with them.

Some dependency configurations have been renamed as of Gradle 7.

By using the Java plugin's built-in functionality to create these archives, they're automatically created as part of a normal build, and included in publications.

Because signing now only happens when publishing the build and only when signatory configuration appears to be available, we can leave the signing block uncommented without getting in the way of people who are just trying to make local builds.

Thanks to “toolchains”, introduced in Gradle v6.7, we can now easily ensure that the library is always built with a Java 8 toolchain, even if Gradle is invoked with something else.

Bnd v6 introduces a `bundle` extension to the the Java plugin's `jar` task, which no longer relies on conventions (which are deprecated). This mostly just clears up a deprecation warning. One warning still remains as long as the Bnd plugin is applied, and there doesn't seem to be anything we can do about it.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update to Gradle 8; resuscitate CI #238

Update to Gradle 8; resuscitate CI #238

Commits on Sep 5, 2023

Update to Gradle 8; resuscitate CI #238

Are you sure you want to change the base?

Update to Gradle 8; resuscitate CI #238

Commits on Sep 5, 2023