GNOME Bugzilla – Bug 765793
configure script failure (cairo_win32_surface_create_with_format is not found in cairo library)
Last modified: 2016-04-30 20:45:02 UTC
There is a test to see if cairo_win32_surface_create_with_format is present in the cairo library. However, the command that compiles/links the test code snippet is incorrect so the test always fails. The fix is to use pkg-config to generate the linker flags instead of hard-coding it to '-lcairo'. From line 21484 of configure: LIBS="-lcairo $LIBS" needs to be: LIBS="$CAIRO_LIBS $LIBS"
Can you provide a git format-patch?
I always forget that the configure script is a built object so you can't edit it directly. LRN proposed a change to configure.ac but it's not yet tested and not in patch form. https://paste.fedoraproject.org/360928/14619072/
AC_CHECK_LIB() does not look in non-standard directories, like /usr/local/lib, and therefore can't find your cairo library. pkg-config does find it, but its finding are not automatically added to $LIBS. There are two ways to fix this. One is to do the > save_LIBS="$LIBS" > LIBS="$CAIRO_LIBS $LIBS" > AC_CHECK_LIB() > LIBS="$save_LIBS" dance. The other is to pass LDFLAGS=-L/usr/local/lib as an argument to configure. Either should work.
Created attachment 327052 [details] [review] W32: support cairo library in non-standard locations When checking for cairo_win32_surface_create_with_format in -lcairo, temporarily put CAIRO_LIBS into LIBS so that AC_CHECK_LIB() can find it in weird places like /usr/local/lib, where gcc would not look on its own.
This situation is somewhat unique: normally we use either pkg-config and AC_*() checks to find stuff. pkg-config is for 3rd-party packages (with versions; we don't check for specific functions, version is new enough => fine), AC_*() is for platform features and non-pkg-config-compatible libraries. cairo is probably the only case when we need to do both (on Windows) due to the way cairo releases are [not?] scheduled. The above explains why this happened in the first place, and why the fix proposed for this bug does not urgently need to be generalized.
How can you call "/usr/local" a "weird" place to put a third party library? I honestly don't know how to respond to that since "/usr/local" is the default prefix!
I think there's some kind of confusion regarding prefixes. If you run configure --help, you'll see that --prefix is listed under "Installation directories". And indeed, first and foremost use of $prefix in configure is to derive directories where [auto]make will install files when you invoke `make install`. Configure *can* use $prefix to look for dependencies, but that has to be deliberate. For example, to find a non-pkg-config library libfoo, developers might add --foo-prefix=..., defaulting its value to $prefix. But on its own configure will never look there for anything. It doesn't even expect you to install anything there - automake documentation says that since accessing /usr/* usually requires root privileges (and thus running `make install` as root), you usually want to override prefix with something else, something user-accessible, like ~/mystuff. Of course, this doesn't really improve your particular situation, as AC_CHECK_LIB won't look in ~/mystuff either. You know what *can* improve your particular situation? Trying one of the fixes i've outlined above (LDFLAGS or the patch). If the patch works, i can push it into master and close this bug as "fixed". If LDFLAGS works, i can wait for someone to try the patch *or* close the bug as "notabug". You can make a difference here. Please do.
Yes, let's close this out. LRN, your configure.ac patch works. In the future let's not use AC_CHECK_LIB() for third party libraries (those not distributed with the compiler) unless we also add the linker flags generated by pkg-config to the LIBS variable like you did in the patch.
Attachment 327052 [details] pushed as 3a095ad - W32: support cairo library in non-standard locations
I tested the commit (https://git.gnome.org/browse/gtk%2B/commit/?id=3a095ad) and it is working.