ci: Add CI job to build on Debian Wheezy #1871

It is widely expected that libsecp256k1, which requires only C89 and <stdint.h>, can be built with any toolchain that meets those requirements, including old and ancient ones.

This PR introduces a CI job that builds on Debian Wheezy, which could serve as a baseline for such expectations.

Wheezy is the earliest Debian release that ships all Autotools components with supported versions (Autoconf>=2.60, Automake>=1.11.2). This allows us to reuse our testing script with minimal adjustments.

~The exact compiler version, GCC 4.4, was chosen to be able to catch issues like this one.~

This PR also raises the following questions:

1. There are some warnings that are excluded from errors:https://github.com/bitcoin-core/secp256k1/blob/5362c070b7682840e4f258a31cc4ef606c39a02f/.github/workflows/ci.yml#L307 Do we want to improve code hygiene and fix them?

2. This branch exposes an example issue with compatibility with retro Linux systems:https://github.com/bitcoin-core/secp256k1/blob/5362c070b7682840e4f258a31cc4ef606c39a02f/.github/workflows/ci.yml#L303-L305 Do we want to fix it?

3. The test script runs make testvectors only if not cross-compiling. But it seems it should run fine even when cross-compiling as it uses Python scripts.

This PR introduces a CI job that builds on Debian Wheezy, which could serve as a baseline for such expectations.

The real baseline in the Debian world is Debian 2.2 Potato, which ships glibc 2.1.3. It's the first Debian release to deliver the <stdint.h> header.

Rebased.

Concept NACK

I think this will be difficult to maintain. At some point, it will break, and then we need to find a new minimum version and get it to run with all its quirks. The goal is not that libsecp256k1 runs on any C89+stdint.h implementation. The goal is that it runs on any reasonable (i.e., contemporary) C89+stdint.h implementation.

There are some warnings that are excluded from errors:

Do we want to improve code hygiene and fix them?

I don't think so. These are compilers bugs.

This branch exposes an example issue with compatibility with retro Linux systems: Do we want to fix it?

I don't think so. The examples are examples. It's by nature that they assume a specific computing environment (e.g., they already assume any of Windows, Linux, or macOS). Assuming a specific version is not a big deal, in particular if it's ancient.

The goal is that it runs on any reasonable (i.e., contemporary) C89+stdint.h implementation.

I still believe that a baseline build environment, perhaps a contemporary one, should be explicitly documented and added as a CI job.

The goal is that it runs on any reasonable (i.e., contemporary) C89+stdint.h implementation.

I still believe that a baseline build environment, perhaps a contemporary one, should be explicitly documented and added as a CI job.

I'm not entirely against this idea, but Wheezy is just ancient. Do you think a Docker image that depends on a generic Debian oldoldstable image could do the job? (Does such an image exist?) This would at least save us from bumping the version regularly.