Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
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
Summary: x11-libs/gtk+-2.12.1-r2 doesn't compile against sys-libs/uclibc-0.9.28.3-r7 a...
Status: VERIFIED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High minor (vote)
Assignee: Embedded Gentoo Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-02 22:08 UTC by Harald Urkan
Modified: 2008-08-05 00:00 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 gentoo-dev 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) gentoo-dev 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) gentoo-dev 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 gentoo-dev 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 gentoo-dev 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.