Cmake gives preference to dynamic libs over static libs, so if you compiled both a dynamic and static version of OCIO, it will still find the dynamic version. To force it to use a static version of a lib you must A) only compile a static version of that lib, B) use CMAKE_LIBRARY_PATH to ensure that only the static version is found, or C) modify FindOpenColorIO.cmake like I've done for ilmbase and openexr <https://github.com/LumaPictures/oiio/commit/969080c28a2927961e7e5372a3ef4e5c03fc063e> .
On Tue, Sep 16, 2014 at 8:35 PM, Dave Lajoie < [email protected]> wrote: > Hello Chad! > > From what I can recall we attempted to statically link OCIO and it didn't > work. Nevertheless we managed to statically link most of the external > libraries. > > I will look at the link, thanks again > 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:30 PM, Chad Dombrova <[email protected]> wrote: > >> You might look into statically linking against the OCIO lib. >> >> I started some work on adding more static linking options to OIIO here: >> https://github.com/LumaPictures/oiio/tree/static_link >> >> I did not test with OCIO, but it should not be too hard to add. >> >> chad. >> >> >> >> On Tue, Sep 16, 2014 at 8:25 PM, Dave Lajoie < >> [email protected]> wrote: >> >>> 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 >>> >>> >> >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
