[ast-developers] #define O_SEARCH O_PATH on Linux missing again

Fedora 19 is *again* missing the #define O_SEARCH to define O_SEARCH
as alias to O_PATH.

Irek

Irek Szczesniak

2013-08-09 19:30:32 UTC

Post by Irek Szczesniak
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?

Irek

Glenn Fowler

2013-08-10 05:46:59 UTC

Post by Irek Szczesniak
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.
/*
* 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 (mockbuild at c6b7.bsys.dev.centos.org)
(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

Irek Szczesniak

2013-08-10 16:37:15 UTC

Post by Irek Szczesniak
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.
/*
* 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.

Post by Irek Szczesniak
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.

Post by Glenn Fowler
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 (mockbuild at c6b7.bsys.dev.centos.org)
(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.

Post by Glenn Fowler
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

Irek Szczesniak

2013-08-10 16:56:30 UTC

Post by Irek Szczesniak
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.
/*
* 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.

Post by Irek Szczesniak
Wasted time: 2h 17 minutes to find out that O_SEARCH was unavailable
in our application. Anyone wanna pay?

FYI I was ranting about the removal of this #error in fcntl.c:
/*
* 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

If #error is triggered then you have no __USE_GNU. Which results in
zero extensions like O_DIRECTORY or O_DIRECT, or on Linux >=3.1 no
O_PATH.

What was the reason for removing that #error? If its triggered then
you have problems and removing the #error doesn't remove the problems
for you.

Irek

Glenn Fowler

2013-08-10 17:18:45 UTC

Post by Irek Szczesniak
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.
/*
* 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.

Post by Irek Szczesniak
Wasted time: 2h 17 minutes to find out that O_SEARCH was unavailable
in our application. Anyone wanna pay?

/*
* 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
If #error is triggered then you have no __USE_GNU. Which results in
zero extensions like O_DIRECTORY or O_DIRECT, or on Linux >=3.1 no
O_PATH.
What was the reason for removing that #error? If its triggered then
you have problems and removing the #error doesn't remove the problems
for you.

I don't like programming in build bombs -- its hard enough getting builds to work
I was concerned that some linux variants + FEATURE/standards might crash a build when
O_PATH etc. are not supported

I'd be willing to add a build triggerred regression report that
lists missing/emulated functionality -- for starters it could be
a small C program that #ifndef's critical macros and lists them at the end of the build
--
#ifdef __linux__
#if !O_SEARCH
printf("package: panic: *** O_SEARCH should be defined in <ast_fcntl.h>\n");
#endif
#endif
--

Roland Mainz

2013-08-10 21:41:37 UTC

[snip]

Post by Irek Szczesniak
/*
* 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.

Post by Irek Szczesniak
Wasted time: 2h 17 minutes to find out that O_SEARCH was unavailable
in our application. Anyone wanna pay?

I don't like programming in build bombs -- its hard enough getting builds to work

Erm... in this case it's IMO better to bomb out early than letting
people search forever in other parts of AST.

Please remember this comment:
-- snip --
/*
* O_PATH is a Linux's variation of O_SEARCH. Since this is treated
* as extension it may not be available without _GNU_SOURCE.
* Even even with _GNU_SOURCE some Linux platforms have bugs in their
* headers which prevents the definition of O_PATH in some hideous
* cases. To prevent all this mess we just grab the octal value and
* define it as O_SEARCH.
* Do not change this. You'll end-up in hell, together with the Linux
* headers. Quickly. - rm
-- snip --
... I usually don't write such comments. This one was born out of very
very bad pain of figuring out why it happens. And that's why I added
the very fatal assert for |__USE_GNU| to ensure that if that logic
fails I don't have to search much further.

Post by Glenn Fowler
I was concerned that some linux variants + FEATURE/standards might crash a build when
O_PATH etc. are not supported

Erm... that can't happen because my original assert tests for
|__USE_GNU| and _not_ |O_PATH| ...

Post by Glenn Fowler
I'd be willing to add a build triggerred regression report that
lists missing/emulated functionality -- for starters it could be
a small C program that #ifndef's critical macros and lists them at the end of the build

Grumpf... the issue is that over time such a report would get very
large and likely quickly ignored because it's not _fatal_ (first rule
of management with IT people: Noone reads reports unless the managers
do this with their staff at the meetings).

The regression that O_PATH doesn't work crept in several alpha
releases ago and ruined a couple of other things quite badly because
they aren't tested properly anymore (while I thought they are tested
because the assert guards against such mistakes from h*ll).

Post by Glenn Fowler
#ifdef __linux__
#if !O_SEARCH
printf("package: panic: *** O_SEARCH should be defined in <ast_fcntl.h>\n");
#endif
#endif

Well... we need to figure out the Linux version and make that an
#error for Linux >= 3.0.0 ... otherwise it's IMO a waste of good code
space... ;-(

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)

Roland Mainz

2013-08-10 23:03:39 UTC

[snip]

Grumpf... the issue is that over time such a report would get very
large and likely quickly ignored because it's not _fatal_ (first rule
of management with IT people: Noone reads reports unless the managers
do this with their staff at the meetings).
The regression that O_PATH doesn't work crept in several alpha
releases ago and ruined a couple of other things quite badly because
they aren't tested properly anymore (while I thought they are tested
because the assert guards against such mistakes from h*ll).

Post by Glenn Fowler
#ifdef __linux__
#if !O_SEARCH
printf("package: panic: *** O_SEARCH should be defined in <ast_fcntl.h>\n");
#endif
#endif

Well... we need to figure out the Linux version and make that an
#error for Linux >= 3.0.0 ... otherwise it's IMO a waste of good code
space... ;-(

Here is a funny detail: If I compile ast-ksh.2013-08-07 with "clang" I get this:
-- snip --
$ grep -E 'O_(SEARCH|PATH)'
<arch/linux.i386-64/include/ast/ast_fcntl.h#ifdef O_PATH
#define O_SEARCH O_PATH
#define O_SEARCH 010000000 /* O_PATH */
-- snip --.
This looks correct.

If I compile with $ gcc -std=gnu1x ... # or $ gcc -std=gnu99 ... # it
works, too. If I compile with $ gcc -std=gnu89 ... # it fails. It
seems the ISO C language version plays a role... and that can not be
set via cpp macros.

Best xxx@@@!!!-idea for tonight: Force C99 mode on Linux with
gcc>=3.x, e.g. if we use gcc >= 3.x on Linux and don't use ISO C >=
C99 then bail out with #error since AFAIK the Linux includes barely
work correctly for anything older than C99 ...

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)

Glenn Fowler

2013-08-12 15:33:25 UTC

Post by Roland Mainz
[snip]

Grumpf... the issue is that over time such a report would get very
large and likely quickly ignored because it's not _fatal_ (first rule
of management with IT people: Noone reads reports unless the managers
do this with their staff at the meetings).
The regression that O_PATH doesn't work crept in several alpha
releases ago and ruined a couple of other things quite badly because
they aren't tested properly anymore (while I thought they are tested
because the assert guards against such mistakes from h*ll).

Post by Glenn Fowler
#ifdef __linux__
#if !O_SEARCH
printf("package: panic: *** O_SEARCH should be defined in <ast_fcntl.h>\n");
#endif
#endif

Well... we need to figure out the Linux version and make that an
#error for Linux >= 3.0.0 ... otherwise it's IMO a waste of good code
space... ;-(

-- snip --
$ grep -E 'O_(SEARCH|PATH)'
<arch/linux.i386-64/include/ast/ast_fcntl.h#ifdef O_PATH
#define O_SEARCH O_PATH
#define O_SEARCH 010000000 /* O_PATH */
-- snip --.
This looks correct.
If I compile with $ gcc -std=gnu1x ... # or $ gcc -std=gnu99 ... # it
works, too. If I compile with $ gcc -std=gnu89 ... # it fails. It
seems the ISO C language version plays a role... and that can not be
set via cpp macros.
gcc>=3.x, e.g. if we use gcc >= 3.x on Linux and don't use ISO C >=
C99 then bail out with #error since AFAIK the Linux includes barely
work correctly for anything older than C99 ...

good analysis

I still don't understand the bailing
someone explicity asking for C foo should get it no?
this is unix after all

how about this
on the linux systems that provide O_PATH is its value always 010000000?

Glenn Fowler

2013-08-12 15:23:32 UTC

Post by Roland Mainz
[snip]

Post by Irek Szczesniak
Wasted time: 2h 17 minutes to find out that O_SEARCH was unavailable
in our application. Anyone wanna pay?

I don't like programming in build bombs -- its hard enough getting builds to work

Erm... in this case it's IMO better to bomb out early than letting
people search forever in other parts of AST.

I don't want build bombs to be a habit because one mistake in one build bomb
results in 100's of messages on and off list and in most cases the people doing the
build are either too busy or not qualified to figure out wht a build failed other
than to send a message that "it didn't build"

Post by Roland Mainz
-- snip --
/*
* O_PATH is a Linux's variation of O_SEARCH. Since this is treated
* as extension it may not be available without _GNU_SOURCE.
* Even even with _GNU_SOURCE some Linux platforms have bugs in their
* headers which prevents the definition of O_PATH in some hideous
* cases. To prevent all this mess we just grab the octal value and
* define it as O_SEARCH.
* Do not change this. You'll end-up in hell, together with the Linux
* headers. Quickly. - rm
-- snip --
... I usually don't write such comments. This one was born out of very
very bad pain of figuring out why it happens. And that's why I added
the very fatal assert for |__USE_GNU| to ensure that if that logic
fails I don't have to search much further.

Post by Glenn Fowler
I was concerned that some linux variants + FEATURE/standards might crash a build when
O_PATH etc. are not supported

Erm... that can't happen because my original assert tests for
|__USE_GNU| and _not_ |O_PATH| ...

so at the point where the build bombs what happens?
say the native headers are broken in 1000 different ways
who is going to be able to fix that?
maybe it results again in 100's of messages on and off list

prior to the the first O_SEARCH patch this wouldn't have made a difference
so what exactly breaks bad enough to cause everyone to fail?
is it as simple as a dir with only search permissions is hit and open fails?

Glenn Fowler

2013-08-10 17:06:38 UTC

Post by Irek Szczesniak
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.
/*
* 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.

Post by Irek Szczesniak
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.

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

there is no portable way to enable standards + extensions
the standard doesn't help here either
on some systems if you don't specify the exact date in _POSIX_foo_bar it fails

this iffe script
src/lib/libast/features/standards
attempts to find a combination that works

in general ast wants "the latest posix + native extensions"
if _GNU_SOURCE does that for linux then try adding this at the top of
src/lib/libast/features/standards and we will trust this
/usr/include/features.h comment:
_GNU_SOURCE All of the above, plus GNU extensions.
--
set stdio
if tst note{ _GNU_SOURCE works }end compile{
#define _GNU_SOURCE 1
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#if !defined(__linux__) || !defined( __USE_GNU)
(
#endif
}end {
#ifndef _GNU_SOURCE
#define _GNU_SOURCE 1
#endif
}
elif ...
--

Roland Mainz

2013-08-10 21:32:33 UTC

[snip]

Post by Irek Szczesniak
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

there is no portable way to enable standards + extensions
the standard doesn't help here either
on some systems if you don't specify the exact date in _POSIX_foo_bar it fails

Right...

Post by Glenn Fowler
this iffe script
src/lib/libast/features/standards
attempts to find a combination that works
in general ast wants "the latest posix + native extensions"
if _GNU_SOURCE does that for linux then try adding this at the top of
src/lib/libast/features/standards and we will trust this
_GNU_SOURCE All of the above, plus GNU extensions.
--
set stdio
if tst note{ _GNU_SOURCE works }end compile{
#define _GNU_SOURCE 1
#include <sys/types.h>
#include <sys/stat.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#if !defined(__linux__) || !defined( __USE_GNU)
(
#endif
}end {
#ifndef _GNU_SOURCE
#define _GNU_SOURCE 1
#endif
}
elif ...

The problem is... it doesn't work. I've dug myself twice through the
Linux includes at night and then found that other distributions have
it different in some weired, patched&&mended way. That's why I set
|__USE_GNU| in fcntl.c "manually" ... there is no way to do it
otherwise to cover all Linux versions in one go.

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)

Glenn Fowler

2013-08-12 22:06:44 UTC

on linux systems where ast failed to see the O_PATH definition
can anyone report an actual value of O_PATH different than
010000000

Roland Mainz

2013-08-13 19:07:05 UTC

Post by Glenn Fowler
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.

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)

Glenn Fowler

2013-08-13 19:51:13 UTC

Post by Glenn Fowler
on linux systems where ast failed to see the O_PATH definition
can anyone report an actual value of O_PATH different than
010000000

-- 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

Glenn Fowler

2013-08-13 14:26:05 UTC

Post by Irek Szczesniak
Fedora 19 is *again* missing the #define O_SEARCH to define O_SEARCH
as alias to O_PATH.

can you replace src/lib/libast/features/fcntl.c with the attached iffe file fcntl.c
and re-run the last alpha build
and verify that O_DIRECTORY and O_SEARCH are defined in the output

thanks

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fcntl.c
Type: application/x-cc
Size: 15808 bytes
Desc: not available
URL: <http://lists.research.att.com/pipermail/ast-developers/attachments/20130813/11bb4c93/attachment-0001.bin>

Roland Mainz

2013-08-13 19:09:22 UTC

Post by Irek Szczesniak
Fedora 19 is *again* missing the #define O_SEARCH to define O_SEARCH
as alias to O_PATH.

can you replace src/lib/libast/features/fcntl.c with the attached iffe file fcntl.c
and re-run the last alpha build
and verify that O_DIRECTORY and O_SEARCH are defined in the output

On Solaris 11/AMD64/64bit and SuSE 12.3/AMD64/64bit it seems to work...
... but see http://lists.research.att.com/pipermail/ast-developers/2013q3/003123.html

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)

Glenn Fowler

2013-08-13 19:52:03 UTC