During a build of samba 3.6.0, I've noticed a failure on linux/inotify.h check. In the config.log there was following error: configure:22866: i686-pc-linux-gnu-gcc -c -O2 -march=athlon -mtune=athlon -pipe -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt -I/usr/include conftest.c >&5 In file included from /usr/include/asm/fcntl.h:1:0, from /usr/include/linux/fcntl.h:4, from /usr/include/linux/inotify.h:11, from conftest.c:541: /usr/include/asm-generic/fcntl.h:132:8: error: redefinition of 'struct f_owner_ex' Given that /usr/include/asm-generic/fcntl.h references a Gentoo bug, I think it's Gentoo specific.
*** Bug 389651 has been marked as a duplicate of this bug. ***
In case it helps (posted this to my bug #389651 marked as dup): Tested installing linux-headers-2.6.39 without applying the gentoo linux-headers patchset (remmed out the src_prepare block) and the problem does not occur. This goes back at least to March 2010 as I noticed that same problem with samba-3.5.1 at that point.
(In reply to comment #2) Given that the problem lies in the solution of bug 244470 it may date even further back. Probably due to some change in glibc.
If this patch is removed from the linux-headers patchset then the samba configure works fine: 00_all_0007-HACK-asm-pull-in-C-library-headers.patch Maybe it's called a HACK for good reason. Of course other stuff may break :)
i've changed the patch for linux-headers-3.1: --- a/include/asm-generic/fcntl.h +++ b/include/asm-generic/fcntl.h @@ -124,7 +124,7 @@ #define F_OWNER_PID 1 #define F_OWNER_PGRP 2 -struct f_owner_ex { +struct __kernel_f_owner_ex { int type; __kernel_pid_t pid; }; @@ -169,7 +169,7 @@ struct f_owner_ex { #define __ARCH_FLOCK_PAD #endif -struct flock { +struct __kernel_flock { short l_type; short l_whence; __kernel_off_t l_start; @@ -186,7 +186,7 @@ struct flock { #define __ARCH_FLOCK64_PAD #endif -struct flock64 { +struct __kernel_flock64 { short l_type; short l_whence; __kernel_loff_t l_start;
(In reply to comment #7) > i've changed the patch for linux-headers-3.1: > > ... ...and that obviously fixes *2.6.39*...how ? I mean, it's good to know it's fixed in the repo, but it's a bit like '-j1' 'fixes' a parallel make problems. Now, if there was at least a silent update of the patchset, it would be a completely different matter.
i'm not bothering with backports
(In reply to comment #9) > i'm not bothering with backports I'm not saying you should, just that "fixed in the repo"!="fixed in the tree".
i didn't say it was fixed in the main tree. but the fix has been queued for the next version, thus for me, this bug is FIXED since i don't have any more work to do for it.
(In reply to comment #11) > i didn't say it was fixed in the main tree. but the fix has been queued for > the next version, thus for me, this bug is FIXED since i don't have any more > work to do for it. As we're already bike-shedding, ain't 'InVCS' keyword usually for it ? Yes, I do know that in *this* bugzilla, both 'keywords' and aliases are rarely in use, short of security or tracker bugs. Not that I personally care much, I'm not a (QA) team member, after all.
i'm not a QA member either. this is how i work. it makes my life simple. in the end, it really makes no difference whatsoever.
Well, as you've already put 3.1 in the tree, the issue is hereby obsolete. My point was such practice makes things harder for both the users (that would search for *open* bugs duplicates) and for bug wranglers. The reasons why this bug didn't gather a long list of duplicates were: - -D_GNU_SOURCE was *required* to trigger this - rarely anyone reads full build log (including many of maintainers) and a failed config check is easy to miss - after the build, such thing as missing inotify support is hard to notice, as usually there are fallbacks implemented Thanks for your work anyway.
i don't care. this is my workflow. you'll have to deal with it.
