Actually I was wrong ( I think ).
Most of the _ZN11OpenColorIO symbols are undefined
Is there way we can compile OIIO to include those symbols without name
space?
> nm /path/path/lib/libOpenImageIO.so.1.4 | grep OpenColorIO
0000000000a33760 d DW.ref._ZTIN11OpenColorIO2v19ExceptionE
U _ZN11OpenColorIO2v113LookTransform6CreateEv
U _ZN11OpenColorIO2v113LookTransform6setDstEPKc
U _ZN11OpenColorIO2v113LookTransform6setSrcEPKc
U _ZN11OpenColorIO2v113LookTransform8setLooksEPKc
U _ZN11OpenColorIO2v115PackedImageDescC1EPfllllll
U _ZN11OpenColorIO2v115PackedImageDescD1Ev
U _ZN11OpenColorIO2v115SetLoggingLevelENS0_12LoggingLevelE
U _ZN11OpenColorIO2v116DisplayTransform10setDisplayEPKc
U
_ZN11OpenColorIO2v116DisplayTransform16setLooksOverrideEPKc
U
_ZN11OpenColorIO2v116DisplayTransform22setInputColorSpaceNameEPKc
U
_ZN11OpenColorIO2v116DisplayTransform23setLooksOverrideEnabledEb
U _ZN11OpenColorIO2v116DisplayTransform6CreateEv
U _ZN11OpenColorIO2v116DisplayTransform7setViewEPKc
U _ZN11OpenColorIO2v116GetCurrentConfigEv
U _ZN11OpenColorIO2v16Config14CreateFromFileEPKc
U _ZN11OpenColorIO2v17Context12setStringVarEPKcS3_
0000000000a35dd0 b _ZN11OpenColorIO2v1L10AutoStrideE
000000000015d730 T _ZN11OpenImageIO4v1_411ColorConfig19supportsOpenColorIOEv
U _ZNK11OpenColorIO2v110ColorSpace7getNameEv
U _ZNK11OpenColorIO2v16Config10getDisplayEi
U _ZNK11OpenColorIO2v16Config11getNumLooksEv
U _ZNK11OpenColorIO2v16Config11getNumViewsEPKc
U _ZNK11OpenColorIO2v16Config12getProcessorEPKcS3_
U
_ZNK11OpenColorIO2v16Config12getProcessorERKNSt3tr110shared_ptrIKNS0_7ContextEEERKNS3_IKNS0_9TransformEEENS0_18TransformDirectionE
U _ZNK11OpenColorIO2v16Config13getColorSpaceEPKc
U _ZNK11OpenColorIO2v16Config14getDefaultViewEPKc
U _ZNK11OpenColorIO2v16Config14getNumDisplaysEv
U _ZNK11OpenColorIO2v16Config17getCurrentContextEv
U _ZNK11OpenColorIO2v16Config17getDefaultDisplayEv
U _ZNK11OpenColorIO2v16Config17getNumColorSpacesEv
U _ZNK11OpenColorIO2v16Config18getLookNameByIndexEi
U _ZNK11OpenColorIO2v16Config24getColorSpaceNameByIndexEi
U _ZNK11OpenColorIO2v16Config7getViewEPKci
U _ZNK11OpenColorIO2v17Context18createEditableCopyEv
U _ZNK11OpenColorIO2v19Processor19hasChannelCrosstalkEv
U _ZNK11OpenColorIO2v19Processor5applyERNS0_9ImageDescE
U _ZNK11OpenColorIO2v19Processor6isNoOpEv
U _ZTIN11OpenColorIO2v19ExceptionE
Tx
Dave
Dave Lajoie
R&D Director | Directeur R&D
[image: Digital-District] <http://www.digital-district.fr> 5605 Avenue de
Gaspé, Suite 408 | Montréal, QC H2T 2A4
Tel (514) 360-3253 ext. 130
On Tue, Sep 16, 2014 at 8:15 PM, Dave Lajoie <
[email protected]> wrote:
> Hello Larry,
>
> The symbol _ZTIN11OpenColorIO2v19ExceptionE is actually present in
> libOpenImageIO.so.1.4 ( our oiio lib, since Mari doesn't provide this
> library, afaik. ) Mari 2.6v2 uses OCIO 1.0.0, while the OpenImage
> lib/python bindings are being compiled against OCIO 1.0.9. I have tried to
> replace OCIO libs in Mari such is uses our libs, but I guess Mari didn't
> like it. App would just hang at startup.
>
> I actually cannot make head or tail about this. I will check with Foundry
> Sorry for the noise. :)
> Dave.
>
>
>
> Dave Lajoie
> R&D Director | Directeur R&D
> [image: Digital-District] <http://www.digital-district.fr> 5605 Avenue
> de Gaspé, Suite 408 | Montréal, QC H2T 2A4
> Tel (514) 360-3253 ext. 130
>
> On Tue, Sep 16, 2014 at 1:47 PM, Dave Lajoie <
> [email protected]> wrote:
>
>> Great! how can you remove OIIO/OCIO from Mari without breaking
>> functionality?
>> We are planning on using OCIO in Mari at some point.
>>
>> Dave.
>>
>> Dave Lajoie
>> R&D Director | Directeur R&D
>> [image: Digital-District] <http://www.digital-district.fr> 5605 Avenue
>> de Gaspé, Suite 408 | Montréal, QC H2T 2A4
>> Tel (514) 360-3253 ext. 130
>>
>> On Tue, Sep 16, 2014 at 12:50 PM, Larry Gritz <[email protected]> wrote:
>>
>>> Is this resolved, then? Is there anything I can do on the OIIO side that
>>> would make it better for you?
>>>
>>> -- lg
>>>
>>>
>>> On Sep 16, 2014, at 9:38 AM, Ashley Retallack <
>>> [email protected]> wrote:
>>>
>>> We ended up removing the OpenColorIO libraries from mari as they were
>>> confusing things and instead using our shared libraries.
>>>
>>> On 16 September 2014 17:13, Dave Lajoie <[email protected]
>>> > wrote:
>>>
>>>> Hello Guys, I don't know if someone has been experiencing the same
>>>> problem.
>>>>
>>>> Basically we have compiled OpenImageIO ( 1.4 and 1.5 master ) along
>>>> with Python Bindings, but whenever the python module is being imported in
>>>> Mari 2.6v2 (Linux CentOS6.5)
>>>>
>>>> We get this error:
>>>>
>>>> Built on 2014-05-30 at 10:14, using Python 2.6.5.
>>>> Welcome to Mari 2.6v2! Type help() to get started.
>>>> >>> import OpenImageIO
>>>> Traceback (most recent call last):
>>>> File "<string>", line 1, in <module>
>>>>
>>>> ImportError: /path/path/path/1.4/lib/libOpenImageIO.so.1.4: undefined
>>>> symbol: _ZTIN11OpenColorIO2v19ExceptionE
>>>>
>>>>
>>>> If I remember correctly, we compiled oiio and components with OCIO
>>>> dependencies, and also we have statically link external libraries, as much
>>>> as possible.
>>>>
>>>> How can I resolve this symbol issue?
>>>> Tx
>>>> Dave.
>>>>
>>>
>>> --
>>> Larry Gritz
>>> [email protected]
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected]
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>>
>>
>
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
