On Tue, 13 Aug 2013 21:07:05 +0200 Roland Mainz wrote: > On Tue, Aug 13, 2013 at 12:06 AM, Glenn Fowler <[email protected]> wrote: > > > > on linux systems where ast failed to see the O_PATH definition > > can anyone report an actual value of O_PATH different than > > 010000000
> Erm... on SuSE 12.3 I get the following results: > -- snip -- > $ grep -r -E '([[:space:]]|_)O_PATH' /usr/include/ > /usr/include/asm-generic/fcntl.h:#ifndef O_PATH > /usr/include/asm-generic/fcntl.h:#define O_PATH 010000000 > /usr/include/bits/fcntl-linux.h:#ifndef __O_PATH > /usr/include/bits/fcntl-linux.h:# define __O_PATH 010000000 > /usr/include/bits/fcntl-linux.h:# define O_PATH __O_PATH > /usr/include/asm-parisc/fcntl.h:#define O_PATH 020000000 > /usr/include/asm-sparc/fcntl.h:#define O_PATH 0x1000000 > -- snip -- > ... which means on Linux/PARISC and Linux/SPARC the values for > |O_PATH| are different. That's the reason why I didn't use |__O_PATH| > in the fcntl.c probe ... O_PATH is defined as |#define O_PATH > __O_PATH| except if the platform-specific fcntl.h defines a different > value for |O_PATH| ... that case |__O_PATH != O_PATH| is true... which > means falling-back to as |010000000| as default O_PATH value doesn't > work on all architectures (and shouldn't be used on non-Linux > platforms either). > I'm at the point where I say that we should use _GNU_SOURCE=1 and try > to get O_PATH. If it isn't set then we should ignore the issue and > complain to Linus himself to get the Linux includes fixed. well its not clear to me what triggers the failure I just changed src/lib/libast/features/standards to test just _GNU_SOURCE first if there is a system that has O_PATH but src/lib/libast/features/fcntl.c doesn't see it then we'd have to rule out compiler options before escalating can you grep the O_DIRECTORY values? then I'll have another features/fcntl.c to test _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
