MINIFICPP-2744 Pin libc++ version in clang CI job

[lordgamez]

The github actions ubuntu image uses a different llvm repository which overrides the libc++ version needed for the clang-20 compilation. Pin the libc++ version on the runner to avoid the version conflict.

https://issues.apache.org/jira/browse/MINIFICPP-2744

---

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced
  in the commit message?

• Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

• Has your PR been rebased against the latest commit within the target branch (typically main)?

• Is your initial contribution a single, squashed commit?

For code changes:

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE file?
• If applicable, have you updated the NOTICE file?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible.

[szaszm]

maybe we should remove whatever llvm repository github added, or use that instead, if the right versions are present in it

[lordgamez]

maybe we should remove whatever llvm repository github added, or use that instead, if the right versions are present in it

Unfortunately we cannot use it because it contains libc++23 and we need libc++20 to be compatible with the current clang-20 compiler. Removing it would be more tricky as I cannot see the internals of the docker image.

[szaszm]

I really don't like this change, because when dependencies are broken, pinning package versions is a hacky workaround that doesn't fix the underlying problem, only makes it work temporarily. But I couldn't really tell you that earlier, without offering a better alternative solution or workaround, which requires digging deeper than usual code review. I did that today.

The problem is not specific to github actions or their ubuntu image: it seems that in their APT repo, LLVM changed their versioned libc++ packages (like libc++1-20, libc++-20-dev, libc++abi.*) to be an empty package with dependency on the main libc++ package, but with a version spec of version = 20. Since we've enabled both llvm-toolchain-jammy and llvm-toolchain-jammy-20, installing libc++-20 from llvm-toolchain-jammy-20 resulted in its libc++1 dependency to be found in llvm-toolchain-jammy, with version = 23, which didn't meet the version requirement. I'm not actually sure about this part, APT errors are cryptic.

I believe LLVM made a mistake by changing their packages to depend on an unversioned libc++ with a package version restriction. According to this comment, the change was intentional, their thinking being that libc++ has an ABI backwards compatibility guarantee, so using a newer libc++ will provide the same functionality, which makes sense, but for some reason, the availability of the newer package causes installation issues anyway with APT. But there is a better alternative workaround:

Remove the lines adding the llvm-toolchain-jammy repos to the repo file. Adding them seems to be a mistake that stems from the confusing docs on apt.llvm.org. They are not necessary to install clang-20 and its dependencies, and removing it prevents apt finding the newer libc++ version that causes the dependency issues.

I've tested the change here: szaszm@4d6f4c5#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fL283

[lordgamez]

I really don't like this change, because when dependencies are broken, pinning package versions is a hacky workaround that doesn't fix the underlying problem, only makes it work temporarily. But I couldn't really tell you that earlier, without offering a better alternative solution or workaround, which requires digging deeper than usual code review. I did that today.

The problem is not specific to github actions or their ubuntu image: it seems that in their APT repo, LLVM changed their versioned libc++ packages (like libc++1-20, libc++-20-dev, libc++abi.*) to be an empty package with dependency on the main libc++ package, but with a version spec of version = 20. Since we've enabled both llvm-toolchain-jammy and llvm-toolchain-jammy-20, installing libc++-20 from llvm-toolchain-jammy-20 resulted in its libc++1 dependency to be found in llvm-toolchain-jammy, with version = 23, which didn't meet the version requirement. I'm not actually sure about this part, APT errors are cryptic.

I believe LLVM made a mistake by changing their packages to depend on an unversioned libc++ with a package version restriction. According to this comment, the change was intentional, their thinking being that libc++ has an ABI backwards compatibility guarantee, so using a newer libc++ will provide the same functionality, which makes sense, but for some reason, the availability of the newer package causes installation issues anyway with APT. But there is a better alternative workaround:

Remove the lines adding the llvm-toolchain-jammy repos to the repo file. Adding them seems to be a mistake that stems from the confusing docs on apt.llvm.org. They are not necessary to install clang-20 and its dependencies, and removing it prevents apt finding the newer libc++ version that causes the dependency issues.

I've tested the change here: szaszm@4d6f4c5#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fL283

Thanks for checking up on this and the detailed explanation, I removed the unnecessary repository from the apt sources in 28dc7e5 Still a bit strange how it only became an issue now when the change seems to be there for months. There were some changes recently in the github runner images but it's unclear what caused the sudden package conflicts.

[szaszm]

I agree it's strange, that's why I'm not quite confident in my hypothesis either, but I feel like the suggested workaround is an improvement either way. Thanks for quickly adopting it