On 09/17/2012 04:14 AM, Roland Mainz wrote:
On Mon, Jul 23, 2012 at 2:24 PM, Glenn Fowler <g...@research.att.com> wrote:
On Mon, 23 Jul 2012 12:24:10 +0200 Michal Hlavinka wrote:
On 07/23/2012 04:45 AM, Glenn Fowler wrote:
I'm finally caught up with the ast-* posts from the last 3 weeks
the posix_spawn thread inspired a new iffe C code test feature
that allows the tests to annotate reasons for test failure
(besides the test not compiling at all, which can be a valid test too)
NOTE("reason text");
can be called (preferably once per failure) and "reason text" will appear
in the iffe --verbose (-v) output on stderr
the new version of iffe will be posted later on Monday
...
...
here is the annotated posix_spawn test
--
linux fails with "ENOEXEC invokes sh"
It was fixed in glibc upstream:
http://sourceware.org/bugzilla/show_bug.cgi?id=13134
It works in all active Fedora releases. It'll work in rhel7. I'll check
what I can do about present rhel releases.
thanks Michal
I should have added that I also read the "fixed" part of the issue
Erm... it's still not working in ast-ksh.2012-09-11. The iffe probe
still prints an error:
-- snip --
iffe: test: posix_spawn exists and it works and its worth using ...
ENOEXEC produces exit status 127 (GOOD) ... yes
-- snip --
... the "GOOD" may be a bit misleading ("GOOD" means "working" ... but
the iffe probe must return "BEST" to reflect that the
|posix_spawn()|-implementatoin is fully POSIX/SUS-conformant...).
I did not find any posix documentation that would make the "GOOD"
behaviour incorrect. I found only this:
> If posix_spawn() or posix_spawnp() fail for any of the reasons that
> would cause fork() or one of the exec family of functions to fail,
> an error value shall be returned as described by fork() and exec,
> respectively (or, if the error occurs after the calling process
> successfully returns, the child process shall exit with exit
> status 127).
So it seems to me everything is fine.
Re topic "|posix_spawn()| still not working in RedHat and SuSE12.2":
It won't work in rhel5 nor rhel6. Glibc maintainers reviewed the changes
and refused to backport that fix:
> The fundamental problem is fixing this issue would require an ABI
> change in glibc. Effectively we'd have to export a glibc-2.15 ABI,
> which is not a change suitable for RHEL 6 which utilizes glibc-2.12.
> For technical reasons it is not possible to introduce
> a glibc-2.12.1 ABI.
>
> FWIW this will work correctly in RHEL 7
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
