GNOME Bugzilla – Bug 578805
goffice cannot compile as aqua on Mac OS X
Last modified: 2009-05-15 14:19:10 UTC
Please describe the problem: Using MacPorts to install Gnucash pure Aqua (no X11). Install fails on goffice with the following error foo-canvas-rect-ellipse.c:45:22: error: gdk/gdkx.h: No such file or directory. Note that this is looking for a file that should not exist in a no_x11 situation. Steps to reproduce: 1. G4 2. OS X 10.5.6 3. Xcode 3.1.2 4. Macports 1.7.1 5. set /opt/local/etc/macports/variants.conf to +no_static +no_x11 -x11 +quartz 5. port install gnucash (+)no_x11 +without_hbci +without_ofx +without_quotes 6. pango will fail see patch in http://trac.macports.org/ticket/18956 7. goffice will fail because there will be no gdk/gdkx.h file Actual results: An error results and goffice will not build Expected results: I expect goffice to build Does this happen every time? yes for various users on various machines see https://trac.macports.org/ticket/18655 Other information: This is a workaround as far as getting goffice to install and gnucash to run (at least data entry is working normally). I do not know what it might be breaking that I'm not seeing. (See patch on trac.) in the file foo-canvas-rect-ellipse.c replace every instance of #ifdef HAVE_RENDER ... #endif with #ifdef HAVE_RENDER #ifdef HAVE_X ... #endif #endif
What do we want to do with this? This is a goffice problem, not a gnucash problem, but obviously affects gc. I've adjusted the bug a bit.
We should assign it to goffice.
I agree. At a previous job, we had the practice of cloning a bug, assigning the clone to the project with the real problem, then setting the original bug into a waiting state. This had the effect of letting the upstream project (in this case goffice) know there was a problem to fix, and keeping track in the downstream project that there is an issue they are waiting on. When the upstream bug is fixed, the downstream bug can be handled. As far as I can tell, there is no way to do this with this bugzilla installation. I suppose we could create a special account called "Bug in dependency" and assign this bug to that account.
Yeah, the way to do it is to make sure you're on the CC list and just reassign. There is no GnuCash bug here at all IMHO.
Reassigned to libgoffice.
My opinion is that we should just remove that XRender code. We just don't use it.
Here's another workaround ... mkdir /opt/local/include/gdk echo "// this is a dummy gdkx.h" > /opt/local/include/gdk/gdkx.h Now Goffice & Gnucash will build without any errors. Hope this info helps.
I find strange that the Xrender test succeeds in configure when X is not available. What am I missing? Anyway, this should be fixed in configure, IMHO.
What version of goffice is this about? Current code says... #ifdef HAVE_RENDER #ifdef HAVE_GDK_X11_DRAWABLE_GET_XDISPLAY #include <gdk/gdkx.h> #endif #include <X11/extensions/Xrender.h> #endif
The bug originally occurred with goffice version 0.6.6_0 installed via MacPorts. This is the latest version available there. What is the actual latest version?
0.6.6 is the latest _stable_ release. It is fixed only in the development releases. (Which are not ABI compatible, so beware!) 0.6.x is seeing very, very little development now. If you can provide a patch to apply against 0.6.x I'll apply it. We will probably need to do a 0.6.7 soonish to deal with some GTK+ abi breakage.
Created attachment 134253 [details] [review] patch file so goffice installs w/o X This is my first patch, so I might not have done it right.
If RENDER is a component of X11, then might be cleaner to have configure only even check for RENDER if we're in X11 GUI mode. If we're not, #1, why bother checking for something that doesn't apply; #2, means code only still needs #ifdef RENDER instead of having to remember additional logic every time render-related things are done.
Before I changed things, the file only checked for render. I don't have render installed because I don't have X11 installed (in MacPorts). Nevertheless, the render test was being passed and then goffice complained about not finding gdkx headers. I inserted the extra check for X11 to fix this. Maybe only checking for X11 or reversing the order of the checks would work, but only checking for render doesn't work.
This should not occur unless you have pkgconfig files in PKG_CONFIG_PATH that should not be there. Or somethings else installs a xrender.pc.
(In reply to comment #14) > Before I changed things, the file only checked for render. I don't have render > installed because I don't have X11 installed (in MacPorts). Nevertheless, the > render test was being passed and then goffice complained about not finding gdkx > headers. I inserted the extra check for X11 to fix this. Maybe only checking > for X11 or reversing the order of the checks would work, but only checking for > render doesn't work. > Not sure if you were responding to me, but I specifically said that the render test would be disabled (and any tokens indicating its presence would be false) in ./configure if x11 were not used.
(In reply to comment #15) > This should not occur unless you have pkgconfig files in PKG_CONFIG_PATH that > should not be there. Or somethings else installs a xrender.pc. > "xrender present without x11 present" is indeed a mess, but it's quite possible to have all of x11 and its extensions present but build gtk for a aqua/quartz graphics instead of x11. It appears that the graphics is only via gtk, not direct x11 calls with the exception of xrender, so instead of checking for "x11 availability", should be checking for "gtk uses x11 gui mode". It doesn't matter whether x11 or its extensions are present if the whole graphics subsystem is configured for something !x11. For example, go-dock-item.c does it sanely: #ifdef GDK_WINDOWING_X11 #include <gdk/gdkx.h> #endif So render #includes and usage should be controlled in the sources using *that* token, not HAVE_X (since x could be present but irrelevant), and/or render shouldn't even be checked (i.e., assumed to be non-present) if that's not the GDK windowing mode.
I backported the fix from the trunk which looks for gdk_x11_drawable_get_xdisplay because that is what is actually used. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.