libOpenImageIO.so.1.7: undefined symbol: _ZTIN11OpenColorIO2v19ExceptionE

[Lars van der Bijl]

Hey guys,

I am using the gaffer build dependencies to build cortex. I am able to build a working version for maya 2017 and houdini 16.5 but when I build it for nuke 10.0.1 I get the following error message.

Traceback (most recent call last):

  File "../nuke/plugins/menu.py", line 48, in <module>

    import IECoreNuke

  File "../IECoreNuke/__init__.py", line 37, in <module>

    from _IECoreNuke import *

ImportError: ../lib/libOpenImageIO.so.1.7: undefined symbol: _ZTIN11OpenColorIO2v19ExceptionE

my guess it's related to the comment in this file.

https://github.com/johnhaddon/dependencies/blob/master/build/buildOCIO.sh

Whats the best way to build cortex for DCC's? 

Should I be able to build all packages up to cortex ones and re-use them during the build of cortex for the DCC's?

3

[Andrew Kaufman]

Your guess sounds about right, though I'd defer to John on those gaffer build.sh scripts, as we don't use them internally at Image Engine.

When it comes to building Cortex for DCCs at a studio, you kind of need to decide if you're going to believe VFX Platform will sort things out for you, or you want to hedge your bets for something safer. Its certainly easier to use one build of everything in all the DCCs, and I think that might work for Maya 2017 + Houdini 16.5 + Nuke 11 (Nuke 10 was targeting a previous VFX Platform), but one of them could have subtly diverged from the platform, so its definitely safer to match each of their dependency specs independently.

You can see how IE does that in our options and build configs. The references to IEEnv in there are just talking about a big dictionary of software versions and their dependencies. We use commandline args to scons called "APP" and "APP_VERSION" to target different DCCs. Note that these only exist for our configs and not in the SConstruct. We use those args in our options file to swap out versions and paths for tbb, boost, exr, alembic, etc that match what the specific DCC requires.

In most cases, you only need to build the Cortex (or Gaffer) dependencies that you want to use for standalone/commandline, because the DCCs should be shipping their dependency libs for you. So if you're building for Nuke 10.0, which requires OCIO 1.0.9 without that shared_ptr flag, then your Cortex options file could setup the paths to point inside the Nuke install directory rather than grabbing the shared libs from the GafferHQ/dependencies package.

Hope that helps. Let us know if there's any other issues you hit.

Cheers,

Andrew

--
--
You received this message because you are subscribed to the "cortexdev" group.
To post to this group, send email to cort...@googlegroups.com
To unsubscribe from this group, send email to cortexdev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cortexdev?hl=en
---
You received this message because you are subscribed to the Google Groups "cortexdev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cortexdev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Andrew Kaufman - R&D Lead

Image Engine

studio: +1 (604) 874-5634 | and...@image-engine.com | www.image-engine.com



15 West 5th Avenue, Vancouver, BC, V5Y 1H4, Canada

If you are not the intended recipient, disclosure, copying, distribution and use of this email is prohibited. Please notify us immediately and delete this email from your systems. You may contact us at in...@image-engine.com if you do not wish to receive further commercial electronic messages. We may still send you messages for which we do not require consent.

[John Haddon]

I don't think this is specifically the `shared_ptr` issue mentioned in the comment you linked, but it certainly does smell like a conflict between the Gaffer build of OpenImageIO/OpenColorIO and the Nuke one. Although VFXPlatform has done a lot to smooth things, the fact is it's still under-specified to guarantee true compatibility between apps.

Please bear in mind that the GafferHQ/dependencies packages are only intended for use in building standalone Gaffer. It's great that you've managed to use them for Maya and Houdini, but we don't provide any guarantees about that. As Andrew says, for our internal builds we still do a lot of work to match the specific DCC versions.

That said, your next steps would be to run with LD_DEBUG to find out which libraries are being loaded at runtime. It looks pretty likely that you're getting Nuke's internal OpenImageIO. You could then run `nm pathToLib.so` to see what symbols it contains, and hopefully get some clues as to why it doesn't contain the needed symbol...

Cheers...

John

John Haddon - R&D Programmer

Image Engine

studio: +1 (604) 874-5634 | jo...@image-engine.com | www.image-engine.com