Created attachment 159648 [details]
Build log for gnome-nibbles
After the Gnome3 update to 3.16 some ports fail to build due to issues with the clutter-gtk3 including multimedia/totem and games/gnome-nibbles. Both fail due to missing linkabes and I am guessing are from a common problem with the new clutter-gtk3 port.
Full build logs attached.
Created attachment 159649 [details]
multimedia/totem build log
Something I forgot to ask, is this with default options?
All use default configurations, not that there are many. multimedia/totem has only one. clutter and its bindings ports (gtk3, gst3) have none.
I compared your configure log with a local one and I can't see any differences. Could you upload your config.log too? thanks.
Created attachment 159701 [details]
I just hit this (updating from totem-3.16.3 to totem-3.16.4 via ports build - previously installed from packages a couple months old).
It occurs because both graphics/clutter-gtk and graphics/clutter-gtk3 are installed and the multimedia/totem configure scripts looks for both (using pkg-config). If it finds both, it adds -I flags for graphics/clutter-gtk first. So it includes the clutter-gtk.h file from graphics/clutter-gtk (/usr/local/include/clutter-1.0/clutter-gtk/clutter-gtk.h) instead of the clutter-gtk.h file from graphics/clutter-gtk3 (/usr/local/include/clutter-gtk-1.0/clutter-gtk/clutter-gtk.h).
That is, it looks like totem tries to be compatible with both older and newer versions of clutter-gtk* and if both are installed (clutter-gtk-0.10.8_6 and clutter-gtk3-1.6.2 in my case), the badness happens. I didn't trace that guess all the way to prove it, but that's my guess. However, it seems very likely that totem would want to use either the older clutter-gtk or the new and not both.
Hmmm... actually, I take that back. It looks like the old clutter-gtk installed its headers to /usr/local/include/clutter-1.0. And totem uses pkg-config to look for >= clutter-1.0 and adds -I flags for that (i.e., headers installed by graphics/clutter). Because the old graphics/clutter-gtk installs its headers there, and totem puts graphics/clutter -I flags before graphics/clutter-gtk3 -I flags, then the old graphics/clutter-gtk include files are included causing the trouble.
In my case, I looked at the things that depended on the old clutter-gtk (pkg info -dr clutter-gtk) and found that there was nothing that depended on it. So I just deleted it and totem built fine.
A better fix might be to fix the totem configure process to allow clutter-gtk and clutter-gtk3 to co-exist - I suppose totem could change its configure script to put clutter-gtk-1.0 in the list of BACKEND_MODULES before clutter-1.0. That would probably work .
But it may be that nothing needs the old graphics/clutter-gtk anymore and it should just be removed. I have not done the ports tree auditing necessary to see if that's true or not.
 I went back later after writing that, installed the old graphics/clutter package, ran 'make patch', modified BACKEND_MODULES in configure to put clutter-gtk-1.0 before clutter-1.0, then did 'make build'. The build completed without error. So that's a workaround and could be fed upstream in theory. I'm not sure it's worth it unless we have something in the tree that needs the old graphics/clutter-gtk.
(In reply to John Hein from comment #6)
I did a quick grep and found that graphics/libchamplain08 depends on graphics/gtk-clutter and graphics/geeqie depends on libchamplain08. That's the only obvious dependency left that I found. I don't know whether geeqie could be updated to avoid depending on these older packages.
(In reply to John Hein from comment #7)
graphics/geeqie only depends on libchamplain08 if the 'GPS' option is on (not on by default).
But I tried forcing graphics/geeqie to use the newer graphics/libchamplain by changing the configure script to point to champlain-0.12 and champlain-gtk-0.12 instead of *-0.8. It configured fine, but failed to build:
bar_gps.c:578:39: error: no member named 'name' in 'struct _ChamplainMapSourceDesc'
So it looks like upstream geeqie needs to release some updates to work with newer libchamplain.
In short, we can't just easily delete the old graphics/clutter-gtk yet because of this dependency at least unless we also mark the GPS option in graphics/geeqie broken.
But if this totem build problem becomes more widely reported, its configure script could be modified (as mentioned in comment 5) to work around old and new installed clutter-gtk* ports.
Just to confirm that moving clutter-gtk-1.0 to before clutter-1.0 does make totem build successfully. htre resulting image rund properly, at least in quick test.
The issue of confused header files, usually in the ordering is really getting to be a pain and, since poudriere always builds ports in a "virgin" environment, it fails to catch those issues which only show up when other ports are installed.
BTW, this is the same issue with games/gnome-nibbles. I moved nine occurrences of clutter-gtk-1.0 from after to before clutter-1.0 and it now builds and installs. (Sorry, but I am guilty of conflating these two problems which should have been separate tickets.)
The problem still exists with the update to gnome-32.18. As I no longer use clutter/gtk, I have deleted it and, as the problem only presents itself when both clutter-gtk and clutter-gtk3 are installed.
Created attachment 201023 [details]
Nobody has said anything on this bug for ~2 years and nothing depends
on graphics/clutter-gtk anymore.
Can we unclutter the tree and remove it?
A commit references this bug:
Date: Thu Jan 31 12:46:54 UTC 2019
New revision: 491713
clutter-gtk 0.10.x is unmaintained upstream and nothing uses it
anymore in the ports tree.
Approved by: gnome (maintainer timeout, 20 days)
Expired port removed.