Any Chance of Reinstating support for Centos7?

[ruubelly]

Hi! Just figured I would share my 2 cents, and see if anyone is up for a discussion on this.

I am currently using or-tools within my centos-7 machines and recently started to think about upgrading to a newer version of or-tools to get some of the newer features.

I then ran across this update...
Updated support from Centos 7 to Centos 8 (#1827) , as a part of release v7.5 (2020-01)

I looked inside issue #1827, and it seems the error is due to some non-default g++ versions on centos 7. There was also a suggested fix as a part of the conversation. It seems there is a way around it by simply installing a version of g++ >= gcc-7.3.

This was the only reason I could find as to why or-tools has moved on from centos7. In my opinion, I don't think this dependency on a particular version of g++ should really warrant dropping the OS as a whole.

Additionally, dropping Centos7 becomes a bit more disappointing when I consider that centos7 will be supported by redhat through 2024, yet centos8 will reach its end of life in December 2021. You can read redhat's official announcement here, but a quick google search can also yield some more background.

Questions

1. Is dropping support for centos7 support solely due to this single issue? Or is there more reasons that I'm missing?
2. Is there any chance of reconsidering centos7 support for or-tools, given that centos7 will outlast centos8?
3. Is anyone else in a similar boat or have similar opinions?

[Mizux]

IIRC all centos related issue/concern/picture:

• No one in the dev team use Centos so the only way for us to try to do the support is through docker image (using a VM e.g. virtualbox to do some test is just too bloated IMHO). -> to support a distro, one mandatory requirement is to be able to use it through docker.
• Google now use C++17 dialect so a distro which doesn't support it will be dropped (ed we don't have the man ressource to adapt the code to support C++11/14 and the code is not guarded by c++17 macro BTW)
• For CI tests we target the last distro release (our typical user journey start with an up to date distro) -> take a look at cmake/docker/centos, makefile/docker/centos and bazel/docker/centos for CI build and tools/docker for release sdk archive.
  note: Since we are using public CI I don't want to "abuse" by testing dozen of release versions (we already have few hours of compilations !)
• Centos6 has been dropped since the docker image use a forbidden syscall on "modern" kernel; i.e. I can't run a docker image on my archlinux
• All distro are supported on a best effort basis and my time being not infinite, My rule of thumb is usually try to support most common distros (alpine, archlinux, debian, centos, fedora, opensuse, ubuntu, freeBSD) I.e. 1) last release and if easy 2) last LTS
  note: For ubuntu last 2 LTS + last release (and also 16.04 LTS just to have an older glibc so we use it as a fallback for users on an unsupported distro i.e. you have good chance to have prebuilt binaries running)
  note2: if I recall correctly python manylinux1 was based on centos6 -> impossible to run, so there new manylinux2010 is now based on
  quay.io/pypa/manylinux2010_x86_64 which is based centos7 ? further details on https://github.com/pypa/manylinux
  EDIT: seems manylinux2010 is based on centos6 and there is a new manylinux2014 -> to investigate...

EDIT 2:

docker run --rm -it quay.io/pypa/manylinux2010_x86_64:latest 
[root@527382948f4f /]# gcc --version
gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)

so manylinux2010 use gcc 8.3.1.

ALL IN ALL feel free to send us a PR with centos7 artifact generation in tools/dockers (need to hack the Makefile and also add some test docker)

[Mizux]

ADDED #2498 (low priority)

[ruubelly]

Thank you so much for your response, I appreciate your insights.

[gregy4]

Well, I had similar problem with VS2017 and google libraries used by or-tools. In days where VS2017 was latest version of compiler, some google libraries weren't compilable since they used latest c++ standard that was not correctly implemented by Microsoft. The problem was fixed only in VS2019 althought it was a bug in VS2017.
In linux situation is much better but more than 5 years can be also a problem. Can you try to update gcc or clang to some newer version and compile or-tools from sources ? I think there's no real support for distributions (no deb or rpm packages for example), only check whether compilation and test are ok on latest versions.
From my experience (primary cp-sat solver), it is always good to be close to latest version since progress in features and performance just over year is significant. This is unfortunatelly not compatible with redhat/centos approach of conservative distribution. Less conservative approach in debian (3years + 2 lts) for example is probably better alternative.

[Mizux]

docker run --rm -it centos:7
# yum install -y centos-release-scl
# yum-config-manager --enable rhel-server-rhscl-9-rpms
# yum install -y devtoolset-9
# scl enable devtoolset-9 bash
## gcc --version
gcc (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2)

IIRC inside a dockerfile each RUN is independant so the scl enable devtoolset-9 bash is not usable.
need to continue digging...