Re: [Nuke-dev] Building exrReaderDeep and exrWriterDeep

[Peter Hillman]

Glad you got this fixed. For what it's worth, the original error you posted looks like it's due to the fact that Nuke shipped with OpenEXR-2.0 before it was officially released, and there were a few changes afterwards.  Perhaps recompiling the OpenEXR library and making Nuke pick that up helped to fix the problem. You may run into stability issues if, for example, somehow both the original exrReaderDeep plugin and your recompiled exrWriterDeep plugin are loaded together. It would be worth building OpenEXR with a custom internal namespace to prevent such clashes, forcing your build of EXR-2.0 to be picked up rather than Nuke's for all your custom EXR plugins: ./configure --enable-namespaceversioining=Imf2_0_Laika No changes to your code should be required, as long as you explicitly link against the correct version of the library. This is advisable even if you statically link against OpenEXR, and certainly wise if you are running into issues with different versions of compilers. Peter On 08/06/13 09:01, Blake Sloan wrote: >> <insert noun of your choosing>, Wombler. On Fri, Jun 7, 2013 at 12:03 PM, Chip Collier <ccoll...@laika.com> wrote: Blake you magnificent <insert noun of your choosing>, that worked! :) Thanks for the information. I now need to go and shimmy all this into a repeatable build so that it's not something that only works on my machine. From: "Blake Sloan" <bsl...@d2.com> To: "Nuke plug-in development discussion" <nuke-dev@support.thefoundry.co.uk> Sent: Friday, June 7, 2013 11:53:48 AM Subject: Re: [Nuke-dev] Building exrReaderDeep and exrWriterDeep Gcc 4.1 is the first part of the sauce. Our cent6 distro does not have it either. Craig spent a day building it. Well 10 minutes, whatever. :) And if your plugin only depends on the c/c++ runtime libs then maybe you're good to go with that. Our simplest internal plugins seem to have deep dependencies on 3rd party packages, all of which had to be built "special-for-nuke" against gcc41. So  it is potentially a major hassle until the Foundry comes up with linux builds for newer OS distros.  On Fri, Jun 7, 2013 at 11:45 AM, Chip Collier <ccoll...@laika.com> wrote: 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! From: "Blake Sloan" <bsl...@d2.com> To: "Nuke plug-in development discussion" <nuke-dev@support.thefoundry.co.uk> 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 <ccoll...@laika.com> 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 Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev -- Blake Sloan Software, Color Digital Domain _______________________________________________ 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 -- Blake Sloan Software, Color Digital Domain _______________________________________________ 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 -- Blake Sloan Software, Color Digital Domain _______________________________________________ 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