C++ compilers

[Larry Gritz]

Honest show of hands: Who is still NOT yet able to handle the VFX Platform 2018 specs for using gcc 6.3 and C++14 compliance and expect that in the turn of 2019 you would be troubled by open source packages that couldn't build with C++11 gcc 4.8?


--
Larry Gritz
l...@larrygritz.com

[David Aguilar]

Nuke is currently a concern. We were able to use a LD_PRELOAD
workaround to make Nuke11 use our c++14 Qt build, but it just feels
wrong. Instead of relying on that it's likely that we're going to keep
Nuke quarantined off in its own environment that's still using the
older C++11 / CY2017 environment.

This works for us because we have the resources to build our entire
tree in multiple permutations of #ifdefs, tool versions, compilers,
and build flags, but it's no small feat and probably quite prohibitive
for smaller shops.

What it effectively means for our internal code is that it has to
remain C++11 compatible because it's still being built in both C++11
and C++14 modes. Right now it works because there aren't any
low-level libraries that are forcing C++14 across public interfaces.


Once challenge was finding all the places where C++11 is hard-coded
and making those places more flexible. Environment variables aren't a
great solution, but for now we are using an environment variable in
our build environment that we've been hacking 3rd-party builds to
honor. A better approach might be to have an external package whose
only purpose is to define the variable build flags (currently
-std=c++14 vs. -std=c++11 and the ABI compatible #define) and make
every vfx open source project depend on it for getting its build
configuration.

That's more work then hacking it in, so you can imagine which one wins
in the short-term. For reference, here's[1] what we added to Ptex.

Follow-up question for the group -- what would be the best way to
manage changing build configurations across all open source vfx
projects? If we have rough consensus then we could start submitting
changes in that vein upstream as we find ourselves needing to change
things rather than making local site-specific tweaks.

Sorry for the long-winded answer. I can't answer on Pixar's behalf,
but from what I've seen they are not ready either since everything in
the tree is still expecting C++11. For reference, we had to make a
similar local tweak to USD here[2] (that change was not shared
upstream) to make it use C++14 rather than C++11, so it seems like
they haven't gotten there yet.

[1] https://github.com/wdas/ptex/blob/master/CMakeLists.txt#L8
[2] https://github.com/PixarAnimationStudios/USD/blob/master/cmake/defaults/gccclangshareddefaults.cmake#L31

An engineer from SideEffects mentioned that they had to make that same
USD tweak as well when building their USD integration for Houdini 17
(which is built in C++14 mode).

> --
> You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
> To post to this group, send email to vfx-platfo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/4F90CE35-C64F-429C-99B6-EFC071B0F08E%40larrygritz.com.
> For more options, visit https://groups.google.com/d/optout.



--
David

[Paul Miller]

No problem here.

I'm more interested in a minimum set of distributions we can target.

[and...@image-engine.com]

We're still using some older/current Maya versions in production (2016, 2017, & 2018), which to my knowledge are still gcc 4.8 c++11. Similarly with Nuke 11. So I'd expect to be using "non compliant" DCCs into 2019, and would hope to still upgrade certain open source packages for use within them.

If any of that is off base, I'd be happy to hear it.

[Aloys Baillet]

Hi,

Such a timely question, thanks Larry!

We are in the middle of (or I hope not too far from) migrating to devtoolset-6 to recompile all our code.

We use rez to manage our packages and that gave us quite some visibility into the scale of the problem, as we have about 500 C++ rez packages to rebuild (we have a few thousands packages in total).

Until now we used a package called stdlib which contained the libstdc++.so and the standard library headers, with a gcc and clang packages referring to it, and all C++ packages having a runtime requirement to it. This allowed us to move to the then newer gcc-4.8.3 while we were on CentOS-6, and we kept this while we moved to CentOS-7.

We started our migration effort to gcc-6 earlier this year by creating a new version of the stdlib package (6.3.1) but that caused a bit of pain and wasn't really going to help in the long term as we couldn't tell if packages were compiled with C++14 or not.

As we now understand the devtoolset tricks a bit better we decided to remove the stdlib runtime requirement as the system (centos-7) stdlibc++.so is indeed enough.

But we still need to maintain at least an older qt build for Maya 2017 and 2018, for nuke, for Houdini 17 and I am going to mention RV which still is stuck in the sickening past of Qt4...

And this means we still need to keep packages built with C++11 and C++14 alongside each other, and I think we should be fine, just following the compatibility issues specified here: https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/6/html/user_guide/sect-gcc-cpp

We choose to recompile all the source we have access to with gcc (or clang when we can), but we will probably have issues with older apps which use C++ standard library as part of their API and were compiled with a previous major version of gcc, here probably lie our dragons...

So I'm not too concerned about packages we have the source code of, but quite worried about keeping older things running that we don't have the source...

And I'll add another question to any studio with similar fine grain package management, are you trying to model the C++ version in any way in your packages?

Cheers,

Aloys

[Trevor Thomson]

Hi,

The way we've been managing the C++11 and C++14 builds is to effectively build unique vfx reference platforms for each version of each DCC--and we build gcc and libstdc++.so (as well as all the vfx platform libraries) into each of those unique platforms.

For example:

<a vfx2017-based platform>/

bin/

gcc # 4.8.3

lib64/

libstdc++.so.6.0.19

and:

<a vfx2018-based platform>/

bin/ 

gcc # 6.4.0

lib64/

libstdc++.so.6.0.22 

It works nicely for compiling (use each platform's compiler to build software for that platform) and runtime (set LD_LIBRARY_PATH to the platform's lib/ and lib64/).  It can get tricky at runtime since if the platform is earlier in the LD_LIBRARY_PATH than the DCC, the platform can override libraries distributed with the DCC--which may or may not be what you'd want...

-Trevor