No inotify syscalls in libc found

faceman

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

PaulBredbury · Watchman Joined: 14 Jul 2005 Posts: 7310

Do you have:

faceman · Posted: Wed Aug 01, 2007 1:00 pm Post subject:

I sure do. I did even before the problem occurred.
_________________
www.impressusart.com

docbrown06 · n00b Joined: 03 Jun 2006 Posts: 10

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

faceman · Posted: Mon Aug 06, 2007 9:41 pm Post subject:

Bump
_________________
www.impressusart.com

Gergan Penkov · NPTL_KERNEL_VERSION="2.6.17"

try adding

assaf · Posted: Tue Aug 21, 2007 6:22 pm Post subject:

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 · Tux's lil' helper Joined: 14 Apr 2003 Posts: 80

This bug might be of interest: https://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 · Apprentice Joined: 26 Jul 2004 Posts: 212 Location: Europe

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 · Posted: Sun Sep 23, 2007 9:33 am Post subject:

gian · Apprentice Joined: 26 Jul 2004 Posts: 212 Location: Europe

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)