Hey Blake!
We are running Fedora 17. The default gcc is 4.7.2. It doesn't look like Fedora maintains a package for gcc 4.1 so I'll try building it and hopefully that'll be the secret sauce. Thanks for the tip! ----- Original Message ----- From: "Blake Sloan" <[email protected]> To: "Nuke plug-in development discussion" <[email protected]> Sent: Friday, June 7, 2013 10:54:26 AM Subject: Re: [Nuke-dev] Building exrReaderDeep and exrWriterDeep Hey Chip. Is your facility on Cent6? If so, it may help you to know that the only way we could get our plugins to work in Nuke on cent6 is to rebuild any library our plugin depends on with gcc41. These package versions are not used for anything but Nuke plugins for cent6. Here's a list if it helps: /tools/package/boost/1.47.0_gcc41/ /tools/package/boost/1.48.0_gcc41/ /tools/package/boost/1.50.0_gcc41/ /tools/package/ilmbase/1.0.3_gcc41/ /tools/package/imagemagick/6.7.9-10_gcc41/ /tools/package/inventor/1.0.0_gcc41/ /tools/package/libraw/0.14.7_gcc41/ /tools/package/openexr/1.7.1_gcc41/ /tools/package/pytrackcore/7.10.0_gcc41/ /tools/package/pytrackcore/7.9.0_gcc41/ /tools/package/yaml-cpp/0.2.5_gcc41/ On Fri, Jun 7, 2013 at 9:31 AM, Chip Collier < [email protected] > wrote: Hello, I'm trying to update the deep exr reader and writer so that it can support a different file extension. I had to modify the exrWriterDeep in a couple of places (removed the include for ImfMisc.h, replaced calls to pixelTypeSize with regular sizeof calls, and replaced Foundry::Type::AtomicCount32 with std::atomic_int) but other than that everything builds fine. Of course building and loading are two different things. Beyond some namespace difference in the openexr 2.0 build that I've created it appears that the libstdc++.so.6 on my system is newer than what is shipped with nuke so I'm unable to load a plugin with a custom openexr build (which uses a namespace that won't conflict with the version shipped with Nuke). If I link directly to the openexr 2.0 build that ships with Nuke I have a problem with a couple of versions of the Imf::TypedAttribute<>::writeValueTo method. As an example: Nuke/7.0v4-64/libIlmImf-Imf_2_0_0.so.20 exports the following: Imf_2_0_0::TypedAttribute<Imath::Matrix44<float>, Imf_2_0_0::Attribute>::writeValueTo(Imf_2_0_0::OStream&, int) const The version of the plugin I'm building is looking for this symbol a bit differently: Imf_2_0_0::TypedAttribute<Imath::Matrix44<float> >::writeValueTo(Imf_2_0_0::OStream&, int) const Would anyone be able to share the options passed to the openexr configure script used to build Nukes version? Or share what version of GCC is used to build Nuke? Thanks! Chip _______________________________________________ Nuke-dev mailing list [email protected] , http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev -- B l a k e S l o a n S o f t w a r e, C o l o r D i g i t a l D o m a i n _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
