No inotify syscalls in libc found

Message

faceman · Post by **faceman** » Wed Aug 01, 2007 12:14 pm

I'm trying to emerge a package which calls for gnome-menus, but I repeatedly get this error:

checking for inotify_init... no
configure: error: No inotify syscalls in libc found - cannot enable inotify support

I've tried downloading the headers and recompiling glibc to no avail (I followed the advice at http://forums.gentoo.org/viewtopic-t-56 ... otify.html).

Anybody have any ideas?

PaulBredbury · Post by **PaulBredbury** » Wed Aug 01, 2007 12:41 pm

Do you have:

Code: Select all

$ grep INOTIFY /usr/src/linux/.config
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y

faceman · Post by **faceman** » Wed Aug 01, 2007 1:00 pm

I sure do. I did even before the problem occurred.

docbrown06 · Post by **docbrown06** » Sun Aug 05, 2007 8:11 am

Unfortunately, I also have the same problem, and hence cannot compile the latest Gnome.

faceman · Post by **faceman** » Mon Aug 06, 2007 9:41 pm

Gergan Penkov · Post by **Gergan Penkov** » Mon Aug 06, 2007 10:18 pm

try adding

Code: Select all

NPTL_KERNEL_VERSION="2.6.17"

or something more than 2.6.13 <- the version adding inotify support to the kernel
to your /etc/make.conf and re-emerge glibc

assaf · Post by **assaf** » Tue Aug 21, 2007 6:22 pm

make sure you have a recent glibc. I had the same problem because I had glibc-2.3.6. Now i've upgraded to glibc-2.5 and it compiles fine.

dstutz97 · Post by **dstutz97** » Thu Aug 30, 2007 5:03 pm

This bug might be of interest: http://bugs.gentoo.org/show_bug.cgi?id=179406

It seems you need to have linux-headers 2.6.17 or higher installed and have glibc built against that.

I just upgraded my glibc today to 2.5-r4 but still had the error, I just upgraded my linux-headers to 2.6.17-r2 and am rebuilding glibc and am hoping it's fixed. In the meantime I just installed an older gnome-menus which appears to work ok.

gian · Post by **gian** » Sun Sep 23, 2007 9:05 am

I use an older version of libc

(I am not the only one, quite a few gentoo users are stuck to that because of some commercial package they use for professional reasons... and you can't ask a large software house to update their interface to threads just because you like it so)

and so have the gnome-menus problem: I manually modified the ebuild and rebuild the digest in order to install gnome-menus....

In the bug link above someone says that "we will never put a inotify USE flag, 'cause you are supposed to be using only the latest ebuilds...".... even if I understand the point, I think that the "minimum overall effort" principle should be used... in other words when "a small step for a developer is a large leap for many users"... sticking to principles can be illogical in many situations.

obviously the other option is that I (and all others still stuck to glibc 2.3.6 for professional or similar reasons) just decide that gentoo is not suitable as production machine when using quite a few commercial applications...

assaf · Post by **assaf** » Sun Sep 23, 2007 9:33 am

gian wrote:obviously the other option is that I (and all others still stuck to glibc 2.3.6 for professional or similar reasons) just decide that gentoo is not suitable as production machine when using quite a few commercial applications...

This is the conclusion i arrived at a while ago. Gentoo is a distribution for living on the edge, or not updating at all (or stopping completely at some point). Otherwise you're entering a world of pain. Ebuilds get removed at some point and then you can't update other stuff. There is no guarantee that they will stay in portage forever (although they stay around for quite a bit).
I don't expect the overworked devs to maintain such legacy, but you (or some user) can always build your own ebuilds and put them in an overlay.

If you want something "stable" go with fedora or something.

gian · Post by **gian** » Sun Sep 23, 2007 11:33 am

You are absolutely right !

but, in fact, nobody asks for "support".
Unsupported backward compatibility is, I think, much less expensive, and sufficient for the users subset I belong to.... in a sense we also live on the edge, but on a different (and sometimes even more sharp) edge... (sometimes it is much more difficult to use "obsoleted" packages that bleeding edge ones...)

anyway, I strongly support the "a small step" vs " a giant leap" explained above.... (nobody is asking for a "real" "obsolete package" support, that would be foolish) and I also wish to stress the fact that the original cuplrits in all this are 2:

1. sw houses that still support their software only on "superstable" releases such as Red Hat enterprise (with a 2.4 kernel!!)
2. glibc developers that decided to remove linuxthread compatibility from glibc > 2.3 (and this could have been easily avoided)