On Fri, 9 Aug 2013 21:30:32 +0200 Irek Szczesniak wrote:
> On Fri, Aug 9, 2013 at 9:07 PM, Irek Szczesniak <[email protected]> wrote:
> > Fedora 19 is *again* missing the #define O_SEARCH to define O_SEARCH
> > as alias to O_PATH.
> This broke a while ago when #define __USE_GNU 1 was moved to
> src/lib/libast/features/standards. Nice attempt but won't work because
> __USE_GNU is an internal flag of the Linux kernel headers and is unset
> by the normal includes in /usr/include. Worst of all the Linux
> includes are broken and only reveal O_PATH if used with __USE_GNU=1.
> What I don't understand: Roland added a safeguard against malfunctions:
> /*
> * Make sure _GNU_SOURCE is active on Linux. Some versions
> * give us serious trouble in this case so we have this
> * assert to *abort* early instead of let us hunt for "ghost
> * bugs"
> */
> #ifdef __linux__
> #ifndef __USE_GNU
> #error "ASSERT: __USE_GNU should be defined by now"
> #endif
> #endif
> This had been introduced to *prevent* this from happening. WTF was
> this assertion removed? This is really the kind of regression which
> should NEVER happen because it fucks up the rest of the applications.
> Wasted time: 2h 17 minutes to find out that O_SEARCH was unavailable
> in our application. Anyone wanna pay?
please illuminate the list on what would happen to the build on a linux system
that provides neither O_SEARCH nor O_PATH
use this to check your system
tw -Pid /usr/include -e "name=='*.h'" egrep -w 'O_PATH|O_SEARCH'
this shows nada on our master source system
version 2.6.32-358.11.1.el6.x86_64 ([email protected])
(gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) )
#1 SMP Wed Jun 12 03:34:52 UTC 2013
also it was my impression that __USE_GNU was hacked to workaround buggy headers
on at least one linux implementation
a more constructive post would specify how to get O_PATH visible on your system
one would assume that defining _GNU_SOURCE should be sufficient
but that should be defined in <ast_standards.h> which also should have been
included first in features/fcntl.c
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
