Apron bounds missing a v in apronext, goblint, and mopsa

[jmid]

As a follow-up to #28182 I poked around for other packages missing a v in its dependency bounds.
In this first batch I found 3 packages missing a v in its apron bound (noting that apron has used a v-based naming scheme since v0.9.12 released 6 years ago):

• mopsa
• apronext
• goblint - only older versions 1.1.1-2.3.0 were missing it

The latter two had their (v)0.9.15 bound added in 41f689d

[jmid]

There are a number of failures, none of which are related to adding a missing v in the bounds

• apronext (or rather conf-gmp-paths) fails to build on opensuse - fixed in Extend conf-gmp-paths to support OpenSuse #28231
• the underlying apron fails to build on macOS - which is known Draft: Fix apron homebrew #26907
• older goblint versions fail to build on FreeBSD and macOS
• mopsa and goblint fail with a number of errors which seem related to the C compiler and libc version

[jmid]

Rebased and force-pushed after #28231 has been merged. This should take care of the apronext failures on OpenSuse.

[jmid]

Oh well, the rerun revealed that conf-mpfr-paths was now failing on OpenSuse Tumbleweed... 🤷
PR to fix that in #28252.

[jmid]

Rebased and force-pushed once again after #28252 has been merged... 🤞

[jmid]

Like why3 in #28254 on Arch, Fedora 42, and OpenSuse Tumbleweed that all switched to gcc.15 we are seeing a bunch of C compiler errors:

goblint.2.1.0 (failed: conflicting types for ‘__goblint_assume_join’; have ‘void(pthread_t)’ {aka ‘void(long unsigned int)’})
goblint.2.2.1 (failed: conflicting types for ‘__goblint_assume_join’; have ‘void(pthread_t)’ {aka ‘void(long unsigned int)’})
goblint.2.3.0 (failed: conflicting types for ‘__goblint_assume_join’; have ‘void(pthread_t)’ {aka ‘void(long unsigned int)’})
mopsa.1.0 (failed: cannot convert ‘const clang::TemplateArgumentLoc’ to ‘const clang::Expr*’)
mopsa.1.1 (failed: no matching function for call to ‘clang::FieldDecl::getBitWidthValue(clang::ASTContext&) const’)

In addition mopsa.1.0 is failing on fedora-41 and ubuntu-24.10 (with gcc.14), and on FreeBSD and macOS homebrew with llvm.19 and llvm.20.1.8, respectively.

On top, there's a number of goblint failures similar to those in #28157 and #28155.

apronext 1.0-1.0.4 fails on macOS arm64 - due to apron.v0.19.14 failing to build.

Finally there's

• opam.2.0 failures
• a goblint.2.0.0 qcheck test failure on riscv64
• FreeBSD and macOS failures
• Windows failures

Again, none of these were caused by adding a missing v.
We can address some of these failures in follow-up PRs after further investigation to keep things focused.
As such this should be good to go.

[mseri]

I agree. This is good to go

[mseri]

Thanks