With gtk+ 2.22 installed, compiz-0.8* fails to compile due to removed gdk functions. The attached two patches, written by Danny Baumann, caused compilation of 0.8.6-r1 to succeed. compiz seems to be functioning without complication, albeit with uber memory leakage.
Created attachment 253309 [details, diff] Patch one of two, replacing deprecated and removed GDK functions
Created attachment 253311 [details, diff] Patch two of two, replacing deprecated and removed GDK functions
Created attachment 253359 [details, diff] compiz-0.8.6-gdk-display-deprecated.patch There's a couple other places both suggesting (the same) single patch that seems a little tidier/doesn't change gdk_display for cairo, but for the proper (non-deprecated) gdk_display calls. http://osdir.com/ml/general/2010-10/msg26743.html http://www.mail-archive.com/pld-cvs-commit@lists.pld-linux.org/msg234872.html
In fact, this patch appears to have been commited into compiz here: http://gitweb.compiz.org/?p=compiz%2Fcore;a=commitdiff_plain;h=5ea5e2130c56d405fcccd63932918fc49ca1f1b9 so it's probably the right one to go for.
(In reply to comment #4) > In fact, this patch appears to have been commited into compiz here: > > http://gitweb.compiz.org/?p=compiz%2Fcore;a=commitdiff_plain;h=5ea5e2130c56d405fcccd63932918fc49ca1f1b9 > > so it's probably the right one to go for. > That would be the second patch. ;) I just applied all changes relating to GDK deprecation locally and the result worked. If only one is required, all the better. Can someone commit this?
The patch works, but in my amd64 system, with portage 2.2.0_alpha2, portage refuses to install the package because of the poor programming practice notices. I couldn't force it to install, despite not having the "strict" nor the "stricter" portage features enabled, and the VERY_BRAVE_OR_VERY_DUMB environment variable did not help. What worked was to include the following header file: /usr/include/gtk-2.0/gdk/gdkgc.h in gtk-window-decorator.c Credit for this fix goes to MadCow108 from the Ubuntu forums.
patch works here too. Can we get it to the tree, please?
Ok, I've just committed this, but I don't have a system running an old gtk, so I've no idea if this will cause problems for them. I guess we'll have to wait for the bug reports to roll in... 5:\
Created attachment 256445 [details] Compilation Log Still failing to compile over here. Even with gdk/gdkgc.h included in file windowdecorator.c, Portage-2.2 still complains about poor programming practice when using gtk+-2.22
Ok, well, if anyone knows the proper fix for this, I'll be happy to apply the appropriate changes. Note though, that I don't have an amd64 architecture to test this on. I've reopened the bug in the interim.
Technically, it's not failing to compile, but portage refuses to install the package due to those "programming practice" issues. Here (amd64, portage 2.2.0_alpha6) compiz-0.8.6-r3 compiles AND installs, when I add the include mentioned in comment #6. In detail, I added the following exact line: #include "/usr/include/gtk-2.0/gdk/gdkgc.h" in line 25 of file gtk-window-decorator.c, just above the existing line: #include "decoration.h" Ivan from comment #9, could you please try again following these exact instructions? Whether this procedure should become the definitive fix for the package, I don't know, but I'm curious about why it's not working for you. (In reply to comment #9) > Created an attachment (id=256445) [details] > Compilation Log > > Still failing to compile over here. > > Even with gdk/gdkgc.h included in file windowdecorator.c, Portage-2.2 still > complains about poor programming practice when using gtk+-2.22 >
Xenon, if you check the patch that's in portage[1], you'll see that on line 9 there is already a #include <gdk/gdkgc.h> at the top of gtk-window-decorator. Hard coding the explicit path to gdkgc would not be a valid solution since the file may not reside there on all user's machines. Could you please check that compiz-0.8.6-r3 compiles and installs fine on your machine? If so, then you two are obviously suffering different problems. If not, then we need to figure out why hard-coding the patch to the specified file works on one machine, but using the include paths automatically doesn't produce an error such as "file not found" on any other machine... [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-wm/compiz/files/compiz-0.8.6-gdk-display-deprecated.patch?revision=1.1&view=markup
I have successfully compiled and installed compiz-0.8.6-r3 before writing my previous comment, following the procedure detailed in the comment itself. Without manually adding the include, I get the same negative result as Ivan. Now I just tried not adding the explicit gdkgc include line, but moving the one provided by the patch to the position I suggested in my comment, and it worked (got a non-blocking QA notice but portage installed the package). I guess this could be a valid solution. What do you think? (In reply to comment #12) > Xenon, if you check the patch that's in portage[1], you'll see that on line 9 > there is already a #include <gdk/gdkgc.h> at the top of gtk-window-decorator. > Hard coding the explicit path to gdkgc would not be a valid solution since the > file may not reside there on all user's machines. Could you please check that > compiz-0.8.6-r3 compiles and installs fine on your machine? If so, then you > two are obviously suffering different problems. If not, then we need to figure > out why hard-coding the patch to the specified file works on one machine, but > using the include paths automatically doesn't produce an error such as "file > not found" on any other machine... > > [1] > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-wm/compiz/files/compiz-0.8.6-gdk-display-deprecated.patch?revision=1.1&view=markup >
Ok, it looks as though including it after defining GDK_DISABLE_DEPRECATED is the only difference between putting it lower down (with the other gdk includes) and putting it higher up. That suggests that we'll now be mixing some deprecated functionality with non-deprecated functionality, which means this is a temporary fix that'll come back to bite us. Hopefully 0.9 will be stable enough not to segfault all the time by then. In the meantime I've altered the patch, and since this only affects whether people can install the program or not, I haven't bumped the revision number. If you haven't been able to install compiz-0.8.6-r3, please try again. Marking this as FIXED, feel free to reopen or comment if it hasn't solved the problem.
Personally, I think every time an ebuild, its patches or anything else in the portage/category/package directory changes there should be a revision bump, so that people who tried to install a package without success (but don't closely follow bugs like this) are easily notified that there's "new hope", so to say. This said, I agree with what you said.