>> <insert noun of your choosing>,

Wombler.


On Fri, Jun 7, 2013 at 12:03 PM, Chip Collier <[email protected]> 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" <[email protected]>
> *To: *"Nuke plug-in development discussion" <
> [email protected]>
> *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 <[email protected]> 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" <[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
>>
>>
>
>
> --
> *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
>
>


-- 
*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

Reply via email to