Thanks for all of the help, will give that a try. We actually remove both libstdc++ and libgcc_s from our internal install of Nuke so we don't run into any conflicts with the newer version of gcc. We don't have any other issues with compiling against boost, openexr, openimageio, etc... but this is the first time I've had to compile anything against OpenColorIO.
On Thu, Mar 10, 2016 at 6:03 PM, Kevin Wheatley < kevin.wheat...@framestore.com> wrote: > 'Josh' > > Quick check shows Nuke 9.0 is running 1.0.9, Nuke 8 is running 1.0.7 > of libOpenColourIO.so, however both look like they are namespaced with > FnOpenColorIO, my build of "1.0.9" and the default OCIO does not have > the Fn prefix - so what ever I was doing did not interfere with > whatever Nuke 8 needed ( I was extending CDL support to include > additional formats in the OCIO CDLTransform node plugin + the python). > I guess Nuke 9 has OCIO more integrated than 8, which could be a > reason it doesn't work. > > However because Nuke internally will be using different symbols to > your version they should be usable within the same binary, but you > might need to be careful with the python bindings to ensure the code > you call in python actually calls your intended version. The other > option would be to try compile with the Fn prefix. > > Compiling with newer g++ you'll want to be careful with compatibility > and libstdc++ which is the type of problem that Blake is referring to. > > Kevin > _______________________________________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev >
_______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
