pkg/kamailio/obs: used more recent gcc for RHEL and CentOS dists

[sergey-safarov]

Pre-Submission Checklist

• [*] Commit message has the format required by CONTRIBUTING guide
• [*] Commits are split per component (core, individual modules, libs, utils, ...)
• [*] Each component has a single commit (if not, squash them into one commit)
• [*] No commits to README files for modules (changes must be done to docbook files
  in doc/ subfolder, the README file is autogenerated)

Type Of Change

• [*] Small bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds new functionality)
• Breaking change (fix or feature that would change existing functionality)

Checklist:

• PR should be backported to stable branches
• Tested changes locally
• Related to issue #XXXX (replace XXXX with an open issue number)

Description

PR upgraded GCC for RPM packaging.

[miconda]

Personally I would prefer to stick with the default of the operating system, rather than compiling with a different compiler version than the rest of the packages are.

What is the actual benefit to have kamailio compiled with a different version that the rest of the packages? For example, what makes it better to have Kamailio compiled with gcc X and on the same system to use MySQL that was compiled with gcc Z?

[sergey-safarov]

I think the main benefit is not required to write code that must be compiled in some way by different GCC versions.
For C code this may be not actual, but for C++ think this applicable.

For example, the old GCC has broken regular expressions support.
More details at signalwire/freeswitch#1046

[sergey-safarov]

One more benefit.
The recent GCC version makes more automatic checks than the old GCC version.
We can enable GCC flags that allow handling warnings as errors.
So any PR that generates a warning will automatically fail automatic checks.

This will improve PR code quality.

[miconda]

I think such benefits can be used in some CI testing, but for shipping packages for specific distros I think it is better to stick to the official compiler coming with the distros. There can be cases when one wants to replace a RPM installation with a git-branch compilation and then the resulting binaries may have different characteristics.

[sergey-safarov]

I think such benefits can be used in some CI testing

Yes, I agreed. Most of the features related to recent GCC version automatic checks may be implemented in CI process.
Yes, definitely we can improve automatic checks in CI builds.

There can be cases when one wants to replace a RPM installation with a git-branch

As options, we can check GCC version used on RPM dist during compilation to make sure used not too old GCC.
And print command that allows installing recent GCC.

For other coins, we can check GCC documentation. Maybe you will find something useful in the section "New Languages and Language specific improvements"
GCC9 release changes
GCC8 release changes
GCC7 release changes
GCC6 release changes
GCC5 release changes

[miconda]

In Kamailio we do not have constraints on compiler versions, but try to follow a C standard, for many years we tried to stick to C89/C90/C95, to work on Unix-variants and old compilers. Now could be a lot of C99/C11, which fine.

But trying to tailor for a specific compiler version is really out of scope. It works with stock gcc and clang on major linux distros. Not sure if still works on icc (intel c compiler) and suncc, as we (or at least I) do not have access to systems providing them.

Again, if one wants to work on some CI/testing with different compilers and suggest eventual improvements, it could be an appreciated effort. But providing packages compiled with a different compiler than the distro's default one is not the norm out there, from my point of view feels like building a distro variant.

I do not see benefits in wasting time to review changes between gcc (or other compilers) versions. It sounds like let's see what changes are in newer libmysqlclient, libssl, libcurl, libev, libevent, ... and the other libs various modules use and then eventually package with their newer version. There is also the variant to build with clang instead of gcc, that opens another door of plenty of options to choose from.

My view is: if we provide Kamailio packages for distro X, we use the stock packages and apps in that distro to build them. There is no significant reason to do otherwise.

[linuxmaniac]

My view is: if we provide Kamailio packages for distro X, we use the stock packages and apps in that distro to build them. There is no significant reason to do otherwise.

Same view here. Use the default version of each distro version

[sergey-safarov]

closing this PR