As found out by armin76 - gnome-menus needs a glibc that contains the symbol inotify_init - and that comes from glibc IF it was built with linux-headers that is new enough: checking for inotify_init... no configure: error: No inotify syscalls in libc found - cannot enable inotify support I think this comes with linux-headers-2.6.17 and newer, but I'm not completely sure. sys-apps/hal does this too, so that ebuild could be an example - need to use mips-headers in some situation, etc. The problem is that we need the user to have built glibc against this newer headers package too. At least linux-headers ebuild itself strongly suggests the user to do that. On top of that HAL also checks that the kernel itself is new enough (probably to check if it has inotify support) - maybe we should do that as well. This bug serves the purpose of reminding me or someone else in the gnome team to look further into this matter at some point. It is also possible we don't have anything useful to do regarding this.
Unless we can check against which linux-headers glibc was built, we're out of luck. Just having the right linux-headers isn't enough. Not much we can do about it ...
maybe what's I'm going to say is just plain stupid and can't be applied here but could we check the output of /lib/libc-2.5.so ? (just type /lib/libc-2.5.so[enter] in a shell, I think the version indicated here is the linux-headers version)
(In reply to comment #1) > Unless we can check against which linux-headers glibc was built, we're out of > luck. Just having the right linux-headers isn't enough. But demanding a new enough linux-headers increases the changes that the user doesn't fail here. linux-headers warns that a glibc re-emerge should typically be done too, etc. Maybe we could even patch the configure failure message to tell what should be done if the configure check fails on inotify_init. Though better to do it on portage level somehow, of course. (In reply to comment #2) > maybe what's I'm going to say is just plain stupid and can't be applied here > but could we check the output of /lib/libc-2.5.so ? > > (just type /lib/libc-2.5.so[enter] in a shell, I think the version indicated > here is the linux-headers version) Right. /lib/libc.so.6 on my machine though...
(In reply to comment #3) > (In reply to comment #1) > > Unless we can check against which linux-headers glibc was built, we're out of > > luck. Just having the right linux-headers isn't enough. > > But demanding a new enough linux-headers increases the changes that the user > doesn't fail here. linux-headers warns that a glibc re-emerge should typically > be done too, etc. > Maybe we could even patch the configure failure message to tell what should be > done if the configure check fails on inotify_init. Though better to do it on > portage level somehow, of course. > yeah, but that's assuming the user can do the math :) (even me I often ignore this message and just update glibc when portage ask) > (In reply to comment #2) > > maybe what's I'm going to say is just plain stupid and can't be applied here > > but could we check the output of /lib/libc-2.5.so ? > > > > (just type /lib/libc-2.5.so[enter] in a shell, I think the version indicated > > here is the linux-headers version) > > Right. /lib/libc.so.6 on my machine though... > it's symlink iirc
I have glibc-2.3.5-r2 and removing the --enable-inotify option from the variable GCONF make the ebuild work flawlessy A new "inotify" use flag could be added to choose if enabling inotify or not.
No, we won't add a useflag for inotify. All our ebuilds assume you'll be running the latest stable stuff from portage. If you decide to cherry-pick your updates, you're on your own. Thanks
erm, still 2.3 is still in the tree I guess we would still have to do something about it. I would go with a einfo Reading gamin ebuild, I just spotted this: $(use_enable kernel_linux inotify) so we might want to change the ebuild anyway to support non linux profiles (wonder why we didn't get bug reports for that yet).
(In reply to comment #7) > Reading gamin ebuild, I just spotted this: > $(use_enable kernel_linux inotify) > > so we might want to change the ebuild anyway to support non linux profiles > (wonder why we didn't get bug reports for that yet). Already been fixed in another bug. As for the original issue here, no sane way to check for this; hardened is @ glibc-2.5 as well now.
maybe a function available in an eclass that would do the kernel + glibc check would be useful for this case ? The current idea I have is this: # readelf -s /lib/libc.so.6 |egrep inotify 659: 000bdbc0 49 FUNC GLOBAL DEFAULT 11 inotify_init@@GLIBC_2.4 1151: 000bdc00 61 FUNC GLOBAL DEFAULT 11 inotify_rm_watch@@GLIBC_2.4 1723: 000bdb80 63 FUNC GLOBAL DEFAULT 11 inotify_add_watch@@GLIBC_2.4 I don't know if this is very portable though so if someone with the right setup could test this, I would be grateful.
Add some autoconf magic to work out if inotify is present and working or not. I did similar for dovecot a year or two ago.
This is related to bug 207081
gnome-menus-2.22* now also uses GIO to monitor files. Inotify is no longer used directly. Closing fixed
