Bug 233752 – x11-libs/gtk+-2.12.1-r2 doesn't compile against sys-libs/uclibc-0.9.28.3-r7 and UCLIBC_HAS_FTW=y

• Product: Gentoo Linux
• Status: VERIFIED FIXED

[Description Harald Urkan 2008-08-02 22:08:13 UTC]

x11-libs/gtk+-2.12.1-r2 (from http://tinderbox.dev.gentoo.org/portage/local/misc/gtk+-2.12.1-r2.ebuild) seems to have a problem with sys-libs/uclibc-0.9.28.3-r7's file tree walker functions.

If uClibc was built with "UCLIBC_HAS_FTW=y", any attempt at emerging gtk+ errors out with the following information:

gtksearchenginesimple.c:203: warning: 'struct FTW' declared inside parameter list
gtksearchenginesimple.c:203: warning: its scope is only this definition or declaration, which is probably not what you want
gtksearchenginesimple.c: In function 'search_thread_func':
gtksearchenginesimple.c:280: warning: implicit declaration of function 'nftw'
gtksearchenginesimple.c:284: error: 'FTW_PHYS' undeclared (first use in this function)
gtksearchenginesimple.c:284: error: (Each undeclared identifier is reported only once
gtksearchenginesimple.c:284: error: for each function it appears in.)
make[4]: *** [gtksearchenginesimple.lo] Error 1


Solution: Rebuild uClibc without FTW.

Reproducible: Always

[Comment 1 Mart Raudsepp 2008-08-03 06:03:55 UTC]

GNOME team does not have access or maintain that ebuild in that tinderbox.
That said, I have been on and off working with solar and co on making gtk+ work with uclibc in portage ebuild version, so I'm keeping us CCed.

Oh, and actually you can try gtk+-2.12.11 from portage. Around 2.12.10-r1 I added a few patches to official portage version to build successfully on a system that has a successfully built glib from somewhere else (glib has the patches that need more discussion and thought and work). Pango from portage could be fine as well, you just might have to locally reduce the glib version requirement on the portage's pango ebuild, it's just that high (rather than one stable series earlier) to ensure Unicode-5.1 support from glib to ensure that pango will have it. You don't need that on an embeeded system.

[Comment 2 Harald Urkan 2008-08-04 00:41:06 UTC]

Indeed, gtk+-2.12.11 builds flawlessly, and it appears to do so independently of uClibs's FTW. Thank you for that!

By the way, after adjusting its RDEPENDs, pango-1.20.3 (from Portage) works as well.

[Comment 3 solar (RETIRED) 2008-08-04 07:19:18 UTC]

Please allow the bugs to be closed by developers so we can order them properly

[Comment 4 solar (RETIRED) 2008-08-04 07:37:15 UTC]

Mart Raudsepp, being en embedded-helper and a gnome guy. Can you please close this bug when the proper resolution when you are happy?

[Comment 5 Mart Raudsepp 2008-08-04 23:57:07 UTC]

I'm not sure what's to do here for me, and you already marked it fixed. I assume you did something with your ebuild in the referenced location, for instance deleted if the portage one is good, or updated it to a copy from portage with pango dep lowered, or pinged me on IRC on what else is to do in the portage version for the gtk+ version ;)

I have no idea why it would start not caring about struct FTW anymore, I guess they made the new update-icon-cache.c code (that freshly uses ftw(3) in gtk+ helper tool code) more portable in a bug fix release or something, so if the OP sees it now works either way, I'm cool with this particular bug being marked as FIXED as it already is :)

[Comment 6 Mart Raudsepp 2008-08-05 00:00:57 UTC]

Sorry, I guess I now understand what you mean with closing this bug. For stuff I co-maintain we don't do anything in regards to RESOLVED vs CLOSED, but if you guys do, I'm satisfied with the thing being fixed (well, WORKSFORME by now) and will mark it as CLOSED.