added fallback ffi dload

[cinatic]

this will help in case ctypes.util find_libary is not working (e.g. in alpine 3.x)

see also
docker-library/python#111 (comment)
#699 (comment)
Kozea/WeasyPrint#784

[liZe]

Wow, I've just tried another (more violent) solution in 509af10. Does it work for you?

[cinatic]

yes i did a quick test it works as good as my change, thanks for the update

[cinatic]

actually it does not work, i think this

lib = ffi.dlopen(path or name)

was meant to be

lib = ffi.dlopen(path or lib_name)

[liZe]

yes i did a quick test it works as good as my change, thanks for the update

Thanks a lot for the quick answer.

actually it does not work, i think this

lib = ffi.dlopen(path or name)

was meant to be

lib = ffi.dlopen(path or lib_name)

Of course!

[Tontyna]

@liZe I suggest to not call find_library at all -- afaik ffi.dlopen() calls it anyway (unless the given name contains dots or slashes, then it tries to load_library first) -- cf. dlopen() in weasyprint.text
That is to say, I don't believe this workaround is a workaround for libraries without soname and a dot-less searchname. IMHO it's the added 'cairo.so.2 that saved the day for @cinatic.

BTW: I'm wondering why cairo-gobject-2 is in the search name list for the cairo library. Isn't cairo-gobject a helper library providing GObject bindings for cairo?

[liZe]

That is to say, I don't believe this workaround is a workaround for libraries without soname and a dot-less searchname. IMHO it's the added 'cairo.so.2 that saved the day for @cinatic.

You're right, we should probably use WeasyPrint's dlopen function (and see if anyone complains).

BTW: I'm wondering why cairo-gobject-2 is in the search name list for the cairo library. Isn't cairo-gobject a helper library providing GObject bindings for cairo?

It was added by #112, and as it was harmless I had merged it. But again you're right, it's probably useless. @redbug312 uses "might" in #112, so we can assume that it actually never helped anyone.

[liZe]

See #63 and #69 too about load_library.

[liZe]

I've open #135, but we should add CI for Windows and Mac before merging.

[Tontyna]

It was added by #112, and as it was harmless.

It is harmless as long as loading cairo-gobject-2 only succeeds when it opens a library with an interface that fulfills our cairo.cdef
Which, of course, is true for all given library search names. Reminds me of css font stacks. Though an ugly font stack doesnt crash the browser...

Main and unsolvable problem when loading a library is that ctypes.util.find_library() and ctypes.CDLL() use different algorithms to detect the requested library.
Not talking about the fact how complicated and sometimes impossible it is on Linux to retrieve the soname, OMG! calling a compiler, catching and grepping its output to get a filename, that's beyond me...
Not talking about the fact that find_library on Linux (intentionally) doesn't return a full path.

CDLL() uses LoadLibrary on Windows, on Posix dlopen is called. If you compare the docs of those OS funtions with the pythonic implementation of find_library you can't but count yourself lucky each time ffi.dlopen() indeed opened exactly the library you wanted...

[redbug312]

@redbug312 uses "might" in #112, so we can assume that it actually never helped anyone.

Sorry that I've misused the word. In my side project, cairo-gobject-2 has to be appended to support PyGObject for Windows. It names its dll library libcairo-gobject-2.dll, thus ctypes.util.find_library and cffi.FFI().dlopen has to search from the name libcairo-gobject-2.

calling a compiler, catching and grepping its output to get a filename

find_library fetches library filename by searching library caches (ldconfig). I think calling linker (gcc) or scanning compiled files (objdump) are just fallback approaches.

Btw, ffi.dlopen doc said default in-line mode already handles magics like prepending lib or appending .so. Then 'libcairo.so' is not required if 'cairo' has been checked.

[Tontyna]

find_library fetches library filename by searching library caches (ldconfig). I think calling linker (gcc) or scanned compiled files (objdump) are just fallback approaches.

Afaik, on Windows find_library only checks Python's os.environ['PATH'}.
Afaik, on Windows, find_library only appends .dll to the given search name. lib, .so and .dylib magics only happens on posix OS.

Are you sure that PyGObject doesnt follow this pattern?

Of course, if PyGObject's cairo library is named libcairo-gobject-2, this search name is required.

[Tontyna]

The PyGObject docs state:

Note that PyGObject currently does not support cairocffi, only pycairo.

I'm almost sure that the libcairo-gobject-2.dll in your site-packages\gnome folder is not the cairo DLL that cairocffi requires. Indeed I believe it's not a Cairo library at all but, as the name says: a libraray that provides gobject bindings for cairo.

[Tontyna]

@redbug312 Can you import and use cairocffi after it dlopened libcairo-gobject-2.dll as its cairo variable?
I mean, cairo = ffi.dlopen() succeeds with any given search name that successfully loads a dll, could be libgraphite2 as well as libpcre-1 -- you won't notice that on import cairocff but when you try to use it, e.g.

from cairocffi import cairo_version_string
print(cairo_version_string())

[redbug312]

Oh I got it, it may just bypasses dlopen, but actually pointed to a wrong dll.

As you've mentioned, apt package also says libcairo-gobject2 is just a wrapper for cairo. Though the code you gave successes and shows '1.15.2' (because it's a wrapper?).

I experiented if all the other entries of dir(cairocffi.cairo) exists (it remains same even if it's pointed to curl-4). It turns out 17 of 589 are absented if it's pointed to libcairo-gobject-2. Even if libcairo-gobject2 is cairo dll, it brings compatibility problem.

Moreover, cairocffi has dropped support for Python < 3.5 in commit c93eb81; PyGObject for Windows only supports Python < 3.5. So it's better to remove libcairo-gobject2 from the searching.

[Tontyna]

the code you gave successes and shows '1.15.2' (because it's a wrapper?).

Yes. The files in the site-packages/gnome folder seem to be a special build (special names, minimized, optimized, patched, ...) for PyGI/PyGObjects.

BTW: The docs I quoted aren't relatet to the PyGObject for Windows on SourceForge but belong to the PyGObject package available on PyPI.