Hi Etienne, I'm on vacation right now so I can't go into too much detail, but I think that your problem is due to symbol visibility. You should enable the cmake flag for hiding symbols so that they don't get picked up by libs in the host application. One caveat: this produces errors with gcc < 4.2. One of our devs here explained it to me and it should be easy to fix. Basically there's a gcc flag for hiding inlined symbols which should not be passed to cmake for gcc < 4.2. He's going to make a pull request next week when he gets back from his vacation.
Chad On Thursday, October 9, 2014, Etienne Fleurant <[email protected]> wrote: > Hi Chad, > > First, let me thank you! Your explanation really helped. I was able to get > oiio compiled and get the oiio python bindings to import in most of the > software we use here, > , but in order to make it work, I had to make some modifications. It > raised some more questions though :) > I first tried to build a dynamic OIIO library that uses static linking for > all dependencies like tiff, jpeg, exr, png, etc. It indeed compiled > correctly, but when I tried to import the > python module in Maya and Guerilla, it complained about conflicting png > and tiff library versions. For example, in Guerilla, trying to load an > ImageBuf of a png file, would yield the following error: > ''' > libpng warning: Application was compiled with png.h from libpng-1.6.10 > libpng warning: Application is running with png.c from libpng-1.2.49 > libpng error: Incompatible libpng version in application and library > ''' > tiff files would load correctly though. > > In Maya, loading an ImageBuf of either a png or a tiff would result in a > crash. > > So I thought about ldd'ing both application's executable and ohhh surprise > (/S) Maya depends on the system's libtiff and libpng and Guerilla only on > libpng. > Now, even after realizing that, I'm still confused as to why (the exact > reason) there is a conflict here. I would've expected that since the image > libraries are statically linked, it would use those for OIIO and not look > for the parent application dependencies?! I mean, loading any file format > directly in python worked flawlessly! > > Is this a limitation with shared librairies that arise when both the > application itself and an external libary use the same lower-level library? > > My current workaround is to build with the system libpng and an older > version of libtiff; I was originally using libtiff 4.0.3, but using 3.9.x > seems to fix the problem. I'm wondering if that is related the header files > available on the system? > > This workaround makes OIIO play nice with Maya and Guerilla, but not with > Mari. > In Mari, I can import the python bindings and do basic tasks successfully, > like loading an Image buffer and writing files, but as soon as I do any > complex process like an ImageBufAlgo operation for example, Mari crashes. > Mari is using its own version of IlmBase, so it might also be related to > the problem above. > > Also, sorry for the late feedback, but I wanted to make sure I had a > chance to do all the tests I needed to do before responding. > > Thanks in advance, > > Etienne > > 2014-09-24 20:11 GMT-04:00 Chad Dombrova <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>: > >> Hi Etienne, >> Can you check if iv is linking against both libIlmImf.a AND >> libIlmThread.a? >> >> IlmImf is dependent on IlmThread (meaning it uses symbols from it, like >> the Mutex ones listed). If you build a dynamic IlmImf library that >> statically links against IlmThread, then those symbols will be contained >> within libIlmImf.so. However, if you build IlmImf statically, it won't >> contain those symbols, even if IlmThread is static. To see the symbols in >> a library, use the nm command (-C flag will use human-readable names for >> the symbols). If the symbol has a U next to it, then it's undefined. For >> dynamic libraries, that means the lib expects to find the symbol at >> runtime, usually enforced via the links visible using the ldd command. If >> the library is static, it means those symbols need to be present when >> linking, which is your case. >> >> A static lib is just an archive of the compiled .o files, so in order for >> libIlmImf.a to contain the symbols from libIlmThread.a, the .o files from >> that archive would first need to be extracted so that they could be added >> along with the newly compiled object files into libIlmImf.a. While this >> is possible, in practice it seems that it is not done very often (for >> example, cmake does not "honor" target_link_libraries when the target is >> a static library, it's just ignored). Confusing, huh? >> >> All of this is to say that when linking against libIlmImf.a, you must >> also link against libIlmThread.a. This may or may not be your problem, but >> I thought I'd explain some of what's going on. The problem may also relate >> to namespaces used when compiling Ilmbase and OpenEXR. >> >> One thing that I've done to get around some of these problem is to build >> a dynamic OIIO library, but use static linking for all the dependencies >> that might conflict with other applications (tiff, jpeg, ocio, exr, etc). >> I made some changes to oiio's cmake to make this possible, which you can >> find here: https://github.com/LumaPictures/oiio/tree/static_link >> >> Hope that helps. >> >> chad. >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> <javascript:_e(%7B%7D,'cvml','[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
