[Dovecot] *notify config for 1.0.x doesn't enable inotify
hi,
the current code has changed include linux/inotify.h to sys/inotify.h since 2006-01-17, but that won't work with inotify*.h as documented in the wiki.
One has to either revert back to linux/inotify.h, or add
#include
to both configure.in and src/lib/ioloop-notify-inotify.c
Or, just symlink sys/inotify.h -> linux/inotify.h.
That's on Debian 3.1 (Sarge).
-- paolo
GPG/PGP id:0x1D5A11A4 - 04FC 8EB9 51A1 5158 1425 BC12 EA57 3382 1D5A 11A4
On Fri, 2007-11-02 at 14:56 +0100, Paolo wrote:
the current code has changed include linux/inotify.h to sys/inotify.h since 2006-01-17, but that won't work with inotify*.h as documented in the wiki.
The wiki entry seems to create /usr/local/include/sys/inotify.h and it
should be possible to include that as
CPPFLAGS='-I /usr/local/include' ./configure --with-notify=inotify
On Fri, Nov 02, 2007 at 06:07:35PM +0200, Timo Sirainen wrote:
On Fri, 2007-11-02 at 14:56 +0100, Paolo wrote:
the current code has changed include linux/inotify.h to sys/inotify.h since 2006-01-17, but that won't work with inotify*.h as documented in the wiki.
The wiki entry seems to create /usr/local/include/sys/inotify.h and it should be possible to include that as
. Maybe the real problem is that if you tried that, the /usr/local/include isn't in the standard include lookup paths. So you should do: CPPFLAGS='-I /usr/local/include' ./configure --with-notify=inotify
indeed, I spent a while to convince the autoconf to look that up, but then I realized the problem isn't the path, the test program always fails, simply because the new defs have been splitted in the 2 files mentioned in the wiki, the problem being that inotify.h doesn't #include inotify-syscalls.h on its own, and compile fails for undefined functions, eg inotify_add_watch(), which instead are defined in the single linux/inotify.h.
Perhaps such "#include
-- paolo
GPG/PGP id:0x1D5A11A4 - 04FC 8EB9 51A1 5158 1425 BC12 EA57 3382 1D5A 11A4
On 2007-11-02 20:42:03 +0100, Paolo wrote:
On Fri, Nov 02, 2007 at 06:07:35PM +0200, Timo Sirainen wrote:
On Fri, 2007-11-02 at 14:56 +0100, Paolo wrote:
the current code has changed include linux/inotify.h to sys/inotify.h since 2006-01-17, but that won't work with inotify*.h as documented in the wiki.
The wiki entry seems to create /usr/local/include/sys/inotify.h and it should be possible to include that as
. Maybe the real problem is that if you tried that, the /usr/local/include isn't in the standard include lookup paths. So you should do: CPPFLAGS='-I /usr/local/include' ./configure --with-notify=inotify
indeed, I spent a while to convince the autoconf to look that up, but then I realized the problem isn't the path, the test program always fails, simply because the new defs have been splitted in the 2 files mentioned in the wiki, the problem being that inotify.h doesn't #include inotify-syscalls.h on its own, and compile fails for undefined functions, eg inotify_add_watch(), which instead are defined in the single linux/inotify.h.
Perhaps such "#include
" should be in inotify.h, but I think those .h are older versions, since current in-kernel inotify.h is just that, all in one.
they old splitted headers were never meant to be used in the userspace. headers in /usr/include/linux/ are in general not meant for userspace apps.
darix-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
On Fri, Nov 02, 2007 at 11:49:03PM +0100, Marcus Rueckert wrote:
instead are defined in the single linux/inotify.h.
Perhaps such "#include
" should be in inotify.h, but I think those .h are older versions, since current in-kernel inotify.h is just that, all in one. they old splitted headers were never meant to be used in the userspace. headers in /usr/include/linux/ are in general not meant for userspace apps.
yep, that's what docs suggest. But we need inotify.h. Do you know any place where to take it from, other then kernel? I see little point in placing the same file under different dir, unless there are (distro's) pkgs that provide it - eg in Debian's 3.1 there's none, in 4.0 there's klibc which places it under /usr/lib/klibc/; but then klibc docs say you're better off using linux/inotify.h if avail. So, what's the point of changing linux/inotify.h to sys/inotify.h if:
- at best, they're just the same
- the 1st is a standard path, the 2nd isn't (no pkgs, need to tweak by hand).
-- paolo
On Fri, 2007-11-02 at 20:42 +0100, Paolo wrote:
indeed, I spent a while to convince the autoconf to look that up, but then I realized the problem isn't the path, the test program always fails, simply because the new defs have been splitted in the 2 files mentioned in the wiki, the problem being that inotify.h doesn't #include inotify-syscalls.h on its own, and compile fails for undefined functions, eg inotify_add_watch(), which instead are defined in the single linux/inotify.h.
If you do like the wiki says, you should have only a single inotify.h file containing also inotify-syscall.h's contents.
On Sat, Nov 03, 2007 at 11:23:57PM +0200, Timo Sirainen wrote:
instead are defined in the single linux/inotify.h.
If you do like the wiki says, you should have only a single inotify.h file containing also inotify-syscall.h's contents.
ahh - now I see it - too small a screen, didn't notice the '>> inotify.h'
ok, sorry for the noise :]
Anyway, I had already recompiled changing back to (distro's kernel-headers pkg) linux/inotify.h as I see little or no point in the sys/notify.h change. As long as one's not using latest, newest glibc which (iirc) has inotify.h on it's own, that is. Not my case till, I guess, Debian Etch moves to oldstable.
thanks
-- paolo
GPG/PGP id:0x1D5A11A4 - 04FC 8EB9 51A1 5158 1425 BC12 EA57 3382 1D5A 11A4
participants (3)
-
Marcus Rueckert
-
Paolo
-
Timo Sirainen