GNOME Bugzilla – Bug 729668
dia-0.97 branch: error: implicit declaration of function 'cairo_ps_surface_create'
Last modified: 2014-07-06 11:00:05 UTC
Created attachment 276016 [details] build.log When built with "--without-cairo" configure option build fails with: libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I./../../lib -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libxml2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libart-2.0 -I/usr/include/libxml2 -I/usr/include/freetype2 -O2 -pipe -march=native -Wall -Werror=declaration-after-statement -Werror=implicit-function-declaration -Wmissing-prototypes -Wmissing-declarations -finline-functions -fstrict-aliasing -Wpointer-arith -Winit-self -Wformat-nonliteral -c diacairo.c -fPIC -DPIC -o .libs/diacairo.o libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I./../../lib -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/libxml2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libart-2.0 -I/usr/include/libxml2 -I/usr/include/freetype2 -O2 -pipe -march=native -Wall -Werror=declaration-after-statement -Werror=implicit-function-declaration -Wmissing-prototypes -Wmissing-declarations -finline-functions -fstrict-aliasing -Wpointer-arith -Winit-self -Wformat-nonliteral -c diacairo-renderer.c -fPIC -DPIC -o .libs/diacairo-renderer.o diacairo-interactive.c: In function 'end_render': diacairo-interactive.c:239:32: warning: unused variable 'renderer' [-Wunused-variable] diacairo-print.c:36:1: warning: 'count_objs' defined but not used [-Wunused-function] diacairo.c: In function 'export_data': diacairo.c:147:5: error: implicit declaration of function 'cairo_ps_surface_create' [-Werror=implicit-function-declaration] diacairo.c:147:23: warning: assignment makes pointer from integer without a cast [enabled by default] diacairo.c:179:5: error: implicit declaration of function 'cairo_pdf_surface_create' [-Werror=implicit-function-declaration] diacairo.c:179:23: warning: assignment makes pointer from integer without a cast [enabled by default] diacairo.c:193:5: error: implicit declaration of function 'cairo_svg_surface_create' [-Werror=implicit-function-declaration] diacairo.c:193:23: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors make[3]: *** [diacairo.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... diacairo-renderer.c: In function '_ellipse': diacairo-renderer.c:581:10: warning: unused variable 'co' [-Wunused-variable] make[3]: Leaving directory `/var/tmp/portage/app-office/dia-0.97.3_pre20140417/work/dia-0.97.2/plug-ins/cairo' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/app-office/dia-0.97.3_pre20140417/work/dia-0.97.2/plug-ins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/app-office/dia-0.97.3_pre20140417/work/dia-0.97.2' make: *** [all] Error 2
There is a proposed fix at: https://bugs.gentoo.org/show_bug.cgi?id=509636#c6
The proposed fix looks right, it is even following the first part of my pasted comment in https://bugs.gentoo.org/show_bug.cgi?id=509636#c7 But the second part of the comment (cairo being required by gtk-2-8) make me wonder if we shouldn't get rid of --without-cairo altogether.
So dia does not have a direct dependency to cairo but gtk, which is a dependency to dia, depends on cairo and the assumption is that libcairo will always be available during compilation due to gtk. Correct? I think assuming the presence of a package because one of your dependencies depends on it is risky. And as a user, even though I have libcairo installed on my machine, I may decide not to have cairo support built in to dia. My personal approach would be getting rid of all the '#ifdef WITH_CAIRO' statements in the code and enabling/disabling code compilation in the Makefile based on '--without-cairo'.
Created attachment 276261 [details] [review] Proposed fix Here's my proposed fix on top of the git tree.
What way is preferred then by upstream? Applying the last proposed fix or forcing cairo support? Thanks :)
Actually I'm indifferent, but pushed the patch to master anyway;) See: https://git.gnome.org/browse/dia/commit/?id=ceb7265b65ed969698c358a850f8ff3ad42cc9d5 (In reply to comment #3) > So dia does not have a direct dependency to cairo but gtk, which is a > dependency to dia, depends on cairo and the assumption is that libcairo will > always be available during compilation due to gtk. Correct? I'd say Dia can be build without direct cairo dependency, but it does not make much sense to do so if GTK+ is newer than 2.8, i.e. cairo is available for the user's system at hand. There will be a significant loss of functionality (growing with quite some newer features). So not only the ability to render antialiased, export to PDF and printing is lost without the cairo plug-in. Additionally the "Standard - Outline" object is gone (=> only 15 icons in the standard area); text conversion to path will be gone. And I don't hesitate to add more features which need cairo. So my advise is to hesitate in disabling cairo just for some minor optimization (of the build environment). > I think assuming > the presence of a package because one of your dependencies depends on it is > risky. > From my understanding having a hard dependency on cairo would not be additional burden, if one of the required dependencies already requires cairo. Yes, some developers might need to install additional development libraries. > And as a user, even though I have libcairo installed on my machine, I may > decide not to have cairo support built in to dia. If a single user takes that decision knowing the fact would be fine. But if some distributor decides to build crippled versions of Dia that would not be what I like. We e.g. got reports from Fedora user that Dia can not export to PDF even with cairo support. > My personal approach would be > getting rid of all the '#ifdef WITH_CAIRO' statements in the code and > enabling/disabling code compilation in the Makefile based on '--without-cairo'. (In reply to comment #5) > What way is preferred then by upstream? Applying the last proposed fix or > forcing cairo support? Thanks :) Pushed to master, thanks for the reminder. Not closing the bug tough, because it is talking of 0-97 branch, which I can't build easily with the computer at hand.
Merged to dia-0-97 branch: https://git.gnome.org/browse/dia/commit/?h=dia-0-97&id=ad54cac7c3f62edc5a8f003aa7a48fd998cda39e