Added more alternative names for dlopen (Mac)

[commx]

While the installation of weasyprint via pip on OS X works without any issues, weasyprint cannot be imported. This is because dlopen'ing the appropriate libraries doesn't work without adding more alternative names to the dlopen call. The additional names have been added with this commit.

[commx]

Another hint for users that have issues using weasyprint installed via pip on OS X:

If you have installed all dependencies (glib2, etc.) via MacPorts, you may want to try to set LD_LIBRARY_PATH before calling python. A permanent solution might be to set that environment variable within your ~/.profile file:

LD_LIBRARY_PATH=/opt/local/lib

After doing so, you might be able to use weasyprint and have ffi find the required libraries without any problems.

[SimonSapin]

Merged, thanks! This seems to be a common problem. Let me know if you need this on PyPI.

By the way, if anyone knows what is the "right" thing to do on OS X (which I don’t use myself) regarding dlopen, library rames, LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH, and the like, I would love to be told so I can fix things up for WeasyPrint and cairocffi.

[commx]

I think there are two options to provide search locations for the libraries: Either using DYLD_FALLBACK_LIBRARY_PATH (which is - according to Apple's Developer Docs - the way to go when overriding optional library paths), or to additionally provide absolute paths to the libraries in the dlopen call (e.g. /opt/local/lib/libpangocairo-1.0.dylib instead of libpangocairo-1.0.dylib).

So finally we could have two ways to achieve this:

• Set DYLD_FALLBACK_LIBRARY_PATH in the environment variables when being on Mac.
• Add platform-dependent tuples that contain common library names for the current platform. For Linux this could contain ('pango-1.0', 'libpango-1.0'), for Mac ('libpango-1.0.dylib', '/opt/local/lib/libpango-1.0.dylib') and so on.

For the Mac dyld documentation, that also covers the use of DYLD_FALLBACK_LIBRARY_PATH etc., take a look at this site.

[SimonSapin]

Using absolute paths would mean have our own mechanism for searching in various directories, which I’d rather not do as it seems redundant with the existing search mechanism that’s used for relative filenames.

Another constraint is that this is not just about getting it to run on one particular system, but making a library that people (who may not be familiar with library) path can use on all kinds of systems by following (hopefully simple) instructions.

[SimonSapin]

Although, without doing a full searching mechanism, it might make sense to hard-code "well-known" directory paths for Homebrew and Macports. Still, I’d rather not have such hacks specific to a given package manager, if possible.