GNOME Bugzilla – Bug 612483
Does not compile with -DGSEAL_ENABLED
Last modified: 2010-04-13 10:39:13 UTC
This module does not build with -DGSEAL_ENABLED. See http://live.gnome.org/GnomeGoals/UseGseal . Note that maybe this report cannot be fixed yet, as GTK+ still misses some accessor functions (see bug 588389, bug 597610) needed for sealing. Also see http://live.gnome.org/GTK%2B/3.0/PendingSealings for current status. The jhbuild output posted here of course only lists the very first error when trying to compile. gst-dialog.c: In function ‘gst_dialog_constructor’: gst-dialog.c:220: error: ‘GtkObject’ has no member named ‘flags’ gst-dialog.c:229: error: ‘GtkWidget’ has no member named ‘parent’ gst-dialog.c:230: error: ‘GtkDialog’ has no member named ‘vbox’ gst-dialog.c: In function ‘gst_dialog_response’: gst-dialog.c:323: error: ‘GtkObject’ has no member named ‘flags’ gst-dialog.c: In function ‘gst_dialog_set_cursor’: gst-dialog.c:419: error: ‘GtkObject’ has no member named ‘flags’ gst-dialog.c:422: error: ‘GtkWidget’ has no member named ‘window’ gst-dialog.c: In function ‘gst_dialog_freeze’: gst-dialog.c:436: error: ‘GtkWidget’ has no member named ‘window’ gst-dialog.c: In function ‘gst_dialog_thaw’: gst-dialog.c:459: error: ‘GtkWidget’ has no member named ‘window’ gst-dialog.c:460: error: ‘GtkWidget’ has no member named ‘window’ gst-dialog.c: In function ‘gst_dialog_get_freeze_level’: gst-dialog.c:471: warning: ‘return’ with no value, in function returning non-void gst-dialog.c: In function ‘gst_dialog_require_authentication_for_widget’: gst-dialog.c:552: error: ‘GtkObject’ has no member named ‘flags’ make[3]: *** [gst-dialog.o] Error 1 make[3]: Leaving directory `/home/andre/svn-gnome/gnome-system-tools/src/common' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/andre/svn-gnome/gnome-system-tools/src' make[1]: *** [all-recursive] Error 1
Created attachment 155897 [details] [review] Initial partial patch Initial patch. Bumps gtk+ dependency to 2.19.7 (needed for at least one accessor function). Unfortunatley not complete as I run with jhbuild into another error: connection.c:741: warning: no previous declaration for ‘general_prepare’ CCLD network-admin /usr/lib/gcc/i686-redhat-linux/4.4.3/../../../libpolkit-gtk-1.so: undefined reference to `polkit_authorization_result_get_local_authority_lock_down' collect2: ld returned 1 exit status make[3]: *** [network-admin] Error 1 make[3]: Leaving directory `/home/andre/svn-gnome/gnome-system-tools/src/network'
Much thanks for the patch! Don't worry about the PolKit error, I'll have a look at it (feels weird to me). If you consider it as OK to commit, then please go on after 2.30 is released (not sure I'll branch before that).
The PolicyKit linking error must come from polkit-gtk, as we don't use polkit_authorization_result_get_local_authority_lock_down() in the gst.
Comment on attachment 155897 [details] [review] Initial partial patch Committed: http://git.gnome.org/browse/gnome-system-tools/commit/?id=3477c4a6ade2a01ffd3eddbedac489485b6dc9ed
Cool thanks!
Milan, do you have plans to soon sync http://git.gnome.org/browse/gnome-system-tools/tree/src/time/e-map/e-map.c with the old copy in http://git.gnome.org/browse/evolution/tree/widgets/misc/e-map.c ? This would solve a huge bunch of GSEAL issues, but I'm apparently too stupid for it. :-)
I had not considered it, but I can put this in the roadmap, yes. I assume you mean we should cherry-pick all the commits that were done in Evolution since we forked? I remember we've done this for a previous G_SEAL()ed function during the previous cycle, but I was not aware we needed more.
Yes, cherry-picking. I'd really recommend it, soon. Just try to compile with -DGSEAL_ENABLE and see the long list of errors in e-map.c, and as you cannot test GSEAL compatibility as warnings instead of errors unfortunately, this blocks any other GSEAL work/testing for g-s-t which is needed for GNOME 3.0.
Created attachment 158192 [details] [review] Fix all remaining -DGSEAL_ENABLE issues except for e-map.c Fix all the rest (except for e-map.c which should be resynced). After applying this and updating e-map.c we will be done.
Created attachment 158216 [details] [review] Sync EMap widget with Evolution Cherry-picking commits would really be too hard, so just sync and re-apply our changes. They are actually very limited, mainly changing the pixmaps dir and C headers includes. The main benefit of this update is to get rid of deprecated GTK+ symbols, to build correclty with -DG_SEAL() enabled.
Patch seems to work, I've been forced to drop the cherry-pick idea because that would have been such a mess for not so much benefit. Changes are relatively limited. I'd still like to understand why the code copied from Evolution doesn't build as-is. It seem they were calling IS_E_MAP() when their code only defined E_IS_MAP(), and there was a conflicting types error about EMapPrivate being defined as typedef struct _EMapPrivate EMapPrivate; (in e-map.h) typedef struct { blah } EMapPrivate; (in e-map.c) I've changed the second declaration to typedef struct _EMapPrivate { blah }; But I don't understand how it works in their code. Thanks for your new patch, BTW. Feel free to commit it.
Comment on attachment 158192 [details] [review] Fix all remaining -DGSEAL_ENABLE issues except for e-map.c Committed: http://git.gnome.org/browse/gnome-system-tools/commit/?id=8bf4330869c31ccbe44923bac404c232699ed9f4
So I've pushed a different version of the patch above, because it appears I wasn't using the right version of EMap from Evolution. The file I've copied was building without fixes. Commit is 5da7699. I've also pushed a patch to remove further deprecated symbols in EMap (commit c64cb6a), which were still in Evolution. I think we're now building correctly with -DGSEAL_ENABLE! Thanks for your help. I'm closing the report as the list of still pending sealings doesn't seem to include areas we use (e.g. GtkStyle and GtkRc). So we're likely done with this issue in the gst.
(In reply to comment #13) > I'm closing the report as the list of still pending sealings doesn't seem to > include areas we use (e.g. GtkStyle and GtkRc). So we're likely done with this > issue in the gst. You are definitely done if g-s-t compiles with -DGSEAL_ENABLE, no matter if any sealing are pending or not, as that part is unrelated. :)