On Wed, Apr 14, 2021 at 4:47 AM Robert Fanner <
robert...@foundry.com> wrote:
>
> Hi David,
>
> That's a very good point to flag. We spent a bit of time pondering the issue earlier, and while I can't speak for the others on the committee I would venture the following.
>
> It is worth mentioning that (by hook or by crook after navigating compiler environment variable/define quirks) people have managed to have vendor apps and plug-ins running on various distros that have different gcc defaults with the current old ABI=0 spec.
>
> From a RHEL/CentOS perspective, keeping the old spec feels like a lowest-friction option for providing support for RHEL 7/CentOS 7 for apps that choose to do so (which I believe offers security patches till 2024) as well as potentially RHEL 8, without needing to recompile "everything".
>
> The obvious caveat with the above (that you've already flagged via the excellent RHEL 7 / RHEL 8 compatibility link) is to avoid depending on certain distro-provided packages/libraries. If you have input on particularly problematic libraries from the unsupported "compatibility level 2" list from your perspective, then that would be very helpful.
>
> All the best,
> Rob
Thanks Rob. Here's some more thoughts I've had on this topic beyond
the immediate compatibility level 2 libraries.
Right now specifying the old ABI provides the least friction for users
on centos/rhel7-ish distros. These distros have the most users in vfx
land today, and these are the versions that vendors officially
support, so the old ABI makes sense in the current old-ABI landscape.
An invisible benefit of using the old ABI is that blissfully ignorant
users, that won't know the finer details of compiler flags and the ABI
change, are able to use distro-provided C++ libraries inside
vendor-provided apps and things generally work. The rhel/centos7 user
base benefits from the old ABI because they retain access to all of
the pre-built C++ packages provided by the distro and third-party
repositories.
Changing the ABI level is a breaking change. RHEL made the breaking
change when they went from v7 to v8 ~ it required them to rebuild the
world so they saved it for a major release.
My opinion is that it'd be good to get this change out of the way
before something like Qt 6 since that is another big change that could
happen in a few years' time. We want to give vendors and studios
runway to transition to the new ABI landscape without other big
changes alongside them.
If we look forward and expect that studios and vendors have plans to
move to or support rhel/centos/rocky8, where distro-provided libraries
and compiler defaults are all using the new ABI, then it might be time
to make the change.
Another factor is that the vfxplatform is effectively forward-looking.
Studios lag in adopting the latest vfxplatform due to vendor-provided
apps that trail behind, so vfx CY2022 might translate to production
calendar year 2023 or even 2024 for some users. By then rhel7 will be
on its last legs of security patch support and we would probably want
to be prioritizing users in the new ABI landscape at that point in
time.
In the future (CY2022?) users should really be on a newer OS version
where the new ABI is the default, so it seems to make sense to make
the ABI change alongside them.
I guess it's really more of a question of when we expect to adopt the
new ABI. There's never really a good time for a breaking change, so it
is a tough one. Are there any vendor considerations around supporting
rhel8 that might be a factor? Is CY2022 too soon? Would Debian/Ubuntu
users say that CY2022 is already too late?
cheers,
--
David