Unable to build on Ubuntu 20.04 #146

Activity

1. allada commented on Jul 8, 2023

   

   allada

   on Jul 8, 2023

   Contributor

   More actions

   @aaronmondal, I think since we have such a light dependency on c++, we should remove c++20 requirement until at least the oldest ubuntu LTO supports c++20. WDYT?

   I am going to revert the patch, since I follow the principle of "revert first ask questions later". Once we settle on how to best address this we can easily add the PR back in.

   In the mean time I am going to write an integration test for 20.04.

   As for 18.04 it reached it's EOL a couple months ago and is in extended maintenance mode. I don't think I want to force support for 18.04, but I think we should "soft" support it (meaning you can install custom packages to make it work). In this case, I think using a non-apt gcc/clang version should fix the issue.
2. aaronmondal commented on Jul 8, 2023

   

   aaronmondal

   on Jul 8, 2023

   Contributor

   More actions

   My preference would be to use "latest" toolchains by default and to add flags/build configs for conditionally enabling backwards compatibility. WDYT about something like this:

   build --cxxopt=-std=c++20 --host_cxxopt=-std=c++20 --repo_env=BAZEL_CXXOPTS=-std=c++20
   build:ubuntu_20 --cxxopt=-std=c++17 --host_cxxopt=-std=c++17 --repo_env=BAZEL_CXXOPTS=-std=c++17
   build:ubuntu_18 --cxxopt=-std=c++14 --host_cxxopt=-std=c++14 --repo_env=BAZEL_CXXOPTS=-std=c++14
   
3. allada commented on Jul 8, 2023

   

   allada

   on Jul 8, 2023

   Contributor

   More actions

   Hmmm, I would prefer to invert this. I guess my concern is that I don't see a huge benefit of using latest c++ version, when we have very few (if any) runtime-c++ code, so using older std versions doesn't seem that big of an issue to me.

   If you feel strongly about this, maybe we should stop relying on system version of gcc/clang/std and make the builds 100% pure (ie: bundle the toolchain). It's a pain to setup, but once it is setup it makes the builds 100% hermetic.
4. aaronmondal commented on Jul 8, 2023

   

   aaronmondal

   on Jul 8, 2023

   Contributor

   More actions

   Since I've ran into such compatibility issues in the past, here is how forwards and backwards compatibility would ideally be handled IMO. This is similar to how LLVM and Bazel handle backwards compatibility while still being "up-to-date".

   • Default to the latest version of everything in main. E.g. the current LLVM main supports only the latest stable versions of GCC and Clang (and e.g. libcxx doesn't even build with GCC 12 😆)
   • Use feature flags and config options to handle backwards compatibility.
   • The oldest supported versions are those that aren't close to EOL/deprecation.

   BUT I feel like this repo is still so much under construction that there is little to no point in adopting such strict rules at the moment. These things also only make sense if all configurations are actually tested. That would put an immense pressure on CI which will probably be needed at some point but seems like overkill at the moment.

   ---

   If you feel strongly about this, maybe we should stop relying on system version of gcc/clang/std and make the builds 100% pure (ie: bundle the toolchain). It's a pain to setup, but once it is setup it makes the builds 100% hermetic.

   This is what rules_ll upstream does 😆 100% pure reproducible toolchain with perfect caching and fully transparent SBOM ❤️

   I wouldn't want to make this a hard requirement because it wouldn't be relevant for most users (and I wouldn't want to force nix onto anyone) but having an opt-in for something like this for a CI workflow could be interesting. I can send a draft PR for it, but we'll have to see whether GitHub CI works with it in "finite time" 😅
5. aaronmondal commented on Jul 8, 2023

   

   aaronmondal

   on Jul 8, 2023

   Contributor

   More actions

   TL;DR: I'm in favor of keeping compatibility with "as old as possible" for now. Maybe changing that line in #147 is the easiest way to do that at the moment.
6. allada

   closed this as completedin #147on Jul 8, 2023
7. allada commented on Jul 8, 2023

   

   allada

   on Jul 8, 2023

   Contributor

   More actions

   Yeah, lets just keep it at c++14 for now. This is a build-time dependency anyway, so users could always build in docker on an older OS then push the binary to another OS version if needed.