OSX: libpng16.16 hard-linked to /usr/local/lib/libpng16.16.dylib

[groakat]

Hi,

Thanks for creating and maintaining the dlib conda package.

If I install dlib and try to import it in OSX, I get the following error:

ImportError: dlopen(/Users/peter/anaconda/lib/python2.7/site-packages/dlib.so, 2): Library not loaded:     /usr/local/lib/libpng16.16.dylib
  Referenced from: /Users/peter/anaconda/lib/python2.7/site-packages/dlib.so
  Reason: image not found

If I get it right, libpng should come with conda (there is a pnglib package), so there might be a conflict in your configure when you compile dlib.

For reference:

I could work around this issue by compiling pnglib by following this tutorial: http://mac-dev-env.patrickbougie.com/libpng/

Plus creating the necessary softlink:

sudo ln -s /usr/local/libpng-1.6.16/lib/libpng16.16.dylib /usr/local/lib/libpng16.16.dylib

[patricksnape]

Hi! Really sorry for the late response, I didn't notice this notification! I have a build for the latest dlib, but I only uploaded it on Linux so far. I'll build the OSX version tonight from my laptop. I'll let you know when it's done so you can try it out, OK?

[patricksnape]

Right, so I'm having trouble replicating this - is this still a problem with the latest 18.15 I've uploaded? Can you possible give some sample code that is causing that error?

[groakat]

It seems to persist. You can check it with otool:

otool -L dlib.so
dlib.so:
    dlib.so (compatibility version 0.0.0, current version 0.0.0)
    @loader_path/../../libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
    @loader_path/../../libpython2.7.dylib (compatibility version 2.7.0, current version 2.7.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
    /usr/local/lib/libpng16.16.dylib (compatibility version 33.0.0, current version 33.0.0)
    @loader_path/../../libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 283.0.0)

You can see that /usr/local/lib/libpng16.16.dylib is linked to the absolute path, while @loader_path/../../libsqlite3.0.dylib is linked relative.

Maybe you can hack it by taking /usr/local/lib/libpng16.16.dylib off the path, or you force the LD_LIBRARY_PATH variable to be only within anaconda (I thought that is standard) in the build-scipt, by doing:

LD_LIBRARY_PATH=$LIBRARY_PATH

[groakat]

Ahh yes, the error comes straight up when I do:

import dlib

[patricksnape]

Yup, this is totally my fault - I'm surprised that even though I told CMake to build libpng it is still linking to my system one. Unfortunately, I don't have my Mac with me, but luckily this is easy to fix and I can fix it tonight!

[groakat]

It is very hard to spot these things without an external tester. I have been fighting conda for my own projects and getting everything right for all the OS is a lot of effort.

On a side note, for my projects I realised that I could not install my Yosemite made OSX conda package on previous OSX versions, because it linked to a OSX graphics library. I see that your package links to the OSX gcc and libSystemB, which might create some compatibility issues. But again, you will only find out once someone with an old OSX comes by and tests it ;)

There is no rush for me as the workaround worked fine for me and I am working on a different project at the moment.

[patricksnape]

I totally agree. You might notice that they are actually Travis and appyveyor yaml files in the repository because I tried to set this all up so that I could just update the meta.yaml and fire off automated builds.

Unfortunately, the free tier on these systems has a time limit for how long builds take and these large C++ projects (particularly things like boost) take way too long to build (they time out and get cancelled before they can be uploaded). Also, I've yet to find free OSX builds because the free Travis tier has been closed to the public. I've invested a very substantial amount of time in getting this projects to build on all platforms, so it's good to see people using them. I literally purchased a Mac just so that I could set up OSX conda builds :)

In terms of compatibility between different ABIs and older operating systems - such is the difficulty in creating binary distribution systems! Given that I've invested this time and effort for the benefit of the academic community for free, I've got no problem telling someone to take the build script and try building it themselves if it's failing on their older OS!

Thanks for pointing this out though, it's just another step I need to remember when building conda packages - to always check that all linked dependencies are relative using otool or ldd.

I'll let you know when it's done anyways - but its great to see people other than myself making use of the effort of creating conda packages!

[patricksnape]

As an update to this - I have got the automated builds working - and have added instructions for manually building. I believe that the png and jpeg issues are fixed across all platforms, so I am going to close this issue.