On Sat, Aug 10, 2013 at 7:46 AM, Glenn Fowler <[email protected]> wrote: > > 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.
I have to apologies for the explicit language. Imagine being under pressure and then find a regression. A regression for which was considered impossible because multiple layers of safeguards had been established to make the AST build fail the hard way in case of a regression. >> 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 Nothing? We're talking about setting __USE_GNU and later checking with #error whether __USE_GNU is still set in case of a programming error later. The goal is to obtain access to O_PATH (and O_DIRECT), which is available in Linux since 3.0.x (stable branch, it wasn't working until fixes were backported into the 3.0.x stable branch). IMO what would be good is to have a check which tests Linux >=3.1 && !defined(O_PATH) == build error because that's impossible. > 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 That is the problem in Linux 3.0.x. The root of all evil is that _GNU_SOURCE is not compatible to all other standards flags you are setting, which forces /usr/include/features.h to undefine __USE_GNU. > 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 That may well be impossible because you enable all standard flags you know about at the same time. Which is promptly rewarded by a #undef __USE_GNU in /usr/include/features.h Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
