Add more GCC and Clang versions to CI.

[neheb]

No description provided.

[neheb]

2024-01-28T22:45:04.1611657Z /usr/bin/ld: libebml.a(EbmlElement.cpp.o): in function `libebml::EbmlDummy::EbmlDummy(libebml::EbmlId const&)':
2024-01-28T22:45:04.1613811Z EbmlElement.cpp:(.text._ZN7libebml9EbmlDummyC2ERKNS_6EbmlIdE[_ZN7libebml9EbmlDummyC5ERKNS_6EbmlIdE]+0x17): undefined reference to `libebml::EbmlDummy::ClassInfos'
2024-01-28T22:45:04.1616380Z collect2: error: ld returned 1 exit status

No idea what this is.

edit: this failure is with GCC7-9.

[neheb]

add_cxx_flag_if_supported seems to be broken looks like.

[robUx4]

Since the alpine targets are using gcc 13, we might drop the basic Linux + gcc 13 target

[robUx4]

The README should be updated to show/remove some of the target status.

[robUx4]

It's been decided VLC will move to C17 (in addition to C++17) and we only support gcc from version 8 and clang from version 8: https://code.videolan.org/videolan/vlc/-/merge_requests/4858

IMO we don't need to support anything older in this new library version.

[neheb]

@robUx4 that's cool.

VLC is not a library. libebml is a much simpler codebase. It also doesn't take much to support older clang/gcc,

[robUx4]

VLC is not a library. libebml is a much simpler codebase. It also doesn't take much to support older clang/gcc,

VLC is a UI on top of libvlc which can be embedded in a lot of places (my day job). But I mention it here because with mkvtoolnix that's the main user of libebml. So if the minimum compiler is gcc 8 and clang 8, we probably don't need to support actively more than that. There's no need to add ugly hacks for these old compilers just because they are somehow supporting C++17.

[robUx4]

Looking at the list of checks, it seems the alpine builds take 2x longer to build. Can we have just one of them ?

[neheb]

@robUx4 which do you prefer?

[robUx4]

Between armhf and aarch64. Whichever would produce more errors. Otherwise the latter because it's more common nowadays.

[robUx4]

riscv would actually be good as well as it seems to have its own set of differences.

[robUx4]

Also WebAssembly is mostly 32-bit and we don't have a Linux 32-bit target. So maybe armhf would be better.

Yesterday I had trouble compiling Google's protobuf on iOS armv7 because of some alignment issues in AppleClang (fixed in Clang 16 which they don't have yet). So an armv7 with an older compiler (in this case not having aligned new) would be good.

[neheb]

@robUx4 reduced to just armhf.