GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:43:42Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8741`System.Directory.getPermissions` fails on read-only filesystem2019-07-07T18:43:42ZHerbert Valerio Riedelhvr@gnu.org`System.Directory.getPermissions` fails on read-only filesystemAlain O'Dea reports in an [email](http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078) that:
```
Prelude> System.Directory.getPermissions "/usr/bin/ld"
*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only ...Alain O'Dea reports in an [email](http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078) that:
```
Prelude> System.Directory.getPermissions "/usr/bin/ld"
*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system)
```
> That seems wrong.
>
> An `access(*, W_OK)` syscall by design should return `EROFS` on a read-only file system by specification.
>
> This breaks Cabal on SmartOS since `/usr` is read-only by design and Cabal calls `getPermissions "/usr/bin/ld"`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`System.Directory.getPermissions` fails on read-only filesystem","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Alain O'Dea reports in an [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078 email] that:\r\n\r\n{{{\r\nPrelude> System.Directory.getPermissions \"/usr/bin/ld\"\r\n*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system)\r\n}}}\r\n> That seems wrong.\r\n>\r\n> An `access(*, W_OK)` syscall by design should return `EROFS` on a read-only file system by specification.\r\n>\r\n> This breaks Cabal on SmartOS since `/usr` is read-only by design and Cabal calls `getPermissions \"/usr/bin/ld\"`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1AlainODeaAlainODeahttps://gitlab.haskell.org/ghc/ghc/-/issues/8433forkProcess masks async exceptions inside the child process2019-07-07T18:45:05ZjoeyhforkProcess masks async exceptions inside the child processFrankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.
FWIW, I have lo...Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.
FWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"forkProcess masks async exceptions inside the child process","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.\r\n\r\nFWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8350shm_open and shm_unlink not detected on openSUSE Linux2019-07-07T18:45:26ZPeter Trommlerptrommler@acm.orgshm_open and shm_unlink not detected on openSUSE LinuxThe test in libraries/unix/configure fails to detect shm_\* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_\* function.
Note: The openSUS...The test in libraries/unix/configure fails to detect shm_\* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_\* function.
Note: The openSUSE linker sets --as-needed by default and hence the order of linker options does matter.
The attached patch fixes the issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"shm_open and shm_unlink not detected on openSUSE Linux","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The test in libraries/unix/configure fails to detect shm_* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_* function.\r\n\r\nNote: The openSUSE linker sets --as-needed by default and hence the order of linker options does matter.\r\n\r\nThe attached patch fixes the issue.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7399Test Posix004 fails in test-suite2019-07-07T18:49:54ZpaulhTest Posix004 fails in test-suiteAfter a standard build of ghc-7.6.1 on debian wheezy, the test-suite fails on the test posix004.
The error given is:
```
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
posix004: unexpected termination cause
*** unexpected f...After a standard build of ghc-7.6.1 on debian wheezy, the test-suite fails on the test posix004.
The error given is:
```
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
posix004: unexpected termination cause
*** unexpected failure for posix004(normal)
```7.8.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/2451New signal-handling API2019-07-07T19:08:30ZSimon MarlowNew signal-handling APIThe current API for handling signals in `System.Posix` is lacking in a couple of ways:
- it isn't modular: there's no way for a library to install a private signal handler,
there is only a singla global handler per signal.
- it isn't...The current API for handling signals in `System.Posix` is lacking in a couple of ways:
- it isn't modular: there's no way for a library to install a private signal handler,
there is only a singla global handler per signal.
- it isn't possible to get hold of the information from `siginfo_t` (#592).
I want to propose a new API. This has already undergone a round of changes after discussion with Duncan Coutts, and we ended up with something quite simple. Haddock docs are here:
[http://www.haskell.org/\~simonmar/unix/System-Posix-Signals.html\#4](http://www.haskell.org/~simonmar/unix/System-Posix-Signals.html#4)
(also attached as `unix-html.tar.gz`).
I have working patches to implement this. The old API is still available, and is reimplemented using the new API. Signal handlers installed using the old API will coexist with those installed using the new API.
The main motivation for this change was so that I could hook the `SIGCHLD` signal in the `System.Process` library without disturbing users of the `System.Posix` library who might also want to install a `SIGCHLD` handler.
Deadline: 1 Aug (2 weeks)7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/9393execvpe should handle ENOTDIR2019-07-07T18:40:35Ziquiwexecvpe should handle ENOTDIRIf PATH environment variable contains non directory component,
execvpe fails by ENOTDIR.
For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo".
```
module Main where
import System.Envi...If PATH environment variable contains non directory component,
execvpe fails by ENOTDIR.
For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo".
```
module Main where
import System.Environment
import System.Posix.Process
main :: IO ()
main = do
env <- getEnvironment
executeFile "echo" True [] (Just env)
return ()
```
```
$ PATH=/tmp/foo:$PATH runghc a.hs
a.hs: echo: executeFile: inappropriate type (Not a directory)
```
See for example, https://github.com/haskell/cabal/issues/1723
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"execvpe should handle ENOTDIR","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If PATH environment variable contains non directory component,\r\nexecvpe fails by ENOTDIR.\r\n\r\nFor example, if \"/tmp/foo\" is a regular file, the following program fails with PATH contains \"/tmp/foo\".\r\n{{{\r\nmodule Main where\r\n\r\nimport System.Environment\r\nimport System.Posix.Process\r\n\r\nmain :: IO ()\r\nmain = do\r\n env <- getEnvironment\r\n executeFile \"echo\" True [] (Just env)\r\n return ()\r\n}}}\r\n\r\n{{{\r\n$ PATH=/tmp/foo:$PATH runghc a.hs \r\na.hs: echo: executeFile: inappropriate type (Not a directory)\r\n}}}\r\n\r\nSee for example, https://github.com/haskell/cabal/issues/1723","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8621Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_...2019-07-07T18:44:14ZjimenezrickPull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)Discussion in the mailing list (I fixed both commented silly issues):
http://www.haskell.org/pipermail/libraries/2013-December/021756.html
Please review this pull request:
https://github.com/jimenezrick/unix/compare/master...file-utils....Discussion in the mailing list (I fixed both commented silly issues):
http://www.haskell.org/pipermail/libraries/2013-December/021756.html
Please review this pull request:
https://github.com/jimenezrick/unix/compare/master...file-utils.patch
If you find interesting this patch, then:
git pull https://github.com/jimenezrick/unix.git file-utils
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Discussion in the mailing list (I fixed both commented silly issues):\r\nhttp://www.haskell.org/pipermail/libraries/2013-December/021756.html\r\n\r\nPlease review this pull request:\r\nhttps://github.com/jimenezrick/unix/compare/master...file-utils.patch\r\n\r\nIf you find interesting this patch, then:\r\ngit pull https://github.com/jimenezrick/unix.git file-utils","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5942implement POSIX confstr() in System/Posix/Unistd.hsc2019-07-07T18:52:54Zclintimplement POSIX confstr() in System/Posix/Unistd.hsc<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | FeatureRequest |
| TypeOfFailure ...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"implement POSIX confstr() in System/Posix/Unistd.hsc","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["confstr"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/11137configure is broken for the unix package2019-07-07T18:31:48Zpgjconfigure is broken for the unix packageA few weeks ago (around November 1, 2015), the FreeBSD builders started to fail building GHC-HEAD with an error message something like that:
```
[...]
/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/unix/dist-install/build/...A few weeks ago (around November 1, 2015), the FreeBSD builders started to fail building GHC-HEAD with an error message something like that:
```
[...]
/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/unix/dist-install/build/libHSunix-2.7.1.0-ghc7.11.20151126.so: undefined reference to `fdatasync'
collect2: error: ld returned 1 exit status
`gcc48' failed in phase `Linker'. (Exit code: 1)
ghc/ghc.mk:121: recipe for target 'ghc/stage2/build/tmp/ghc-stage2' failed
gmake[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
Makefile:121: recipe for target 'all' failed
gmake: *** [all] Error 2
```
That is because `fdatasync(2)` is not implemented on FreeBSD. Apparently, it is handled in the respective file (`System/Posix/Unistd.hsc`), though it relies on the variable (`HAVE_FDATASYNC`) generated at the `configure` phase. But for some reason, the `configure` script of the `unix` package fails to detect this as it says the following:
```
"inplace/bin/ghc-cabal" configure libraries/unix dist-install "" --with-ghc="/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc-stage1" --with-ghc-pkg="/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour="/usr/local/bin/HsColour" --configure-option=CFLAGS="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline " --configure-option=--with-iconv-includes="/usr/local/include" --configure-option=--with-iconv-libraries="/usr/local/lib" --configure-option=--with-gmp-includes="/usr/local/include" --configure-option=--with-gmp-libraries="/usr/local/lib" --with-gcc="/usr/local/bin/gcc48" --with-ld="/usr/local/bin/ld" --configure-option=--with-cc="/usr/local/bin/gcc48" --with-ar="/usr/local/bin/ar" --with-alex="/usr/local/bin/alex" --with-happy="/usr/local/bin/happy"
Configuring unix-2.7.1.0...
[...]
checking for fdatasync... yes
```
That is the corresponding part of the `config.log`:
```
configure:4242: checking for fdatasync
configure:4263: /usr/local/bin/gcc48 -c -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5
conftest.c: In function 'main':
conftest.c:71:1: warning: implicit declaration of function 'fdatasync' [-Wimplicit-function-declaration]
fdatasync(4);
^
configure:4263: $? = 0
configure:4271: result: yes
```
Looks like GCC is willing to compile the test code, although it notes that it cannot find the declaration of the `fdatasync()` function. Unfortunately, the `configure` script does not instruct GCC to do any linking or be serious on such warnings, so it happily proceeds.
For the reference, previously the `config.log` said something like that instead:
```
configure:4230: checking for fdatasync
configure:4230: /usr/local/bin/gcc48 -o conftest -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5
/tmp//ccDCjZtO.o: In function `main':
conftest.c:(.text+0xa): undefined reference to `fdatasync'
collect2: error: ld returned 1 exit status
configure:4230: $? = 1
[...]
```
I am inclined to think that this is caused by the commit [b06446edd4753f964a46d27ddae864fad97adc13](https://github.com/haskell/unix/commit/b06446edd4753f964a46d27ddae864fad97adc13) for the `unix` package. Perhaps the following change can fix that, at least it fixed for me:
```
--- a/mk/warnings.mk
+++ b/mk/warnings.mk
@@ -16,6 +16,7 @@ SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable
endif
# gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined
SRC_CC_WARNING_OPTS += -Wno-error=inline
+SRC_CC_WARNING_OPTS += -Werror=implicit-function-declaration
endif
else
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"configure is broken for the unix package","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A few weeks ago (around November 1, 2015), the FreeBSD builders started to fail building GHC-HEAD with an error message something like that:\r\n\r\n{{{\r\n[...]\r\n/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/unix/dist-install/build/libHSunix-2.7.1.0-ghc7.11.20151126.so: undefined reference to `fdatasync'\r\ncollect2: error: ld returned 1 exit status\r\n`gcc48' failed in phase `Linker'. (Exit code: 1)\r\nghc/ghc.mk:121: recipe for target 'ghc/stage2/build/tmp/ghc-stage2' failed\r\ngmake[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1\r\nMakefile:121: recipe for target 'all' failed\r\ngmake: *** [all] Error 2\r\n}}}\r\n\r\nThat is because {{{fdatasync(2)}}} is not implemented on FreeBSD. Apparently, it is handled in the respective file ({{{System/Posix/Unistd.hsc}}}), though it relies on the variable ({{{HAVE_FDATASYNC}}}) generated at the {{{configure}}} phase. But for some reason, the {{{configure}}} script of the {{{unix}}} package fails to detect this as it says the following:\r\n\r\n{{{\r\n\"inplace/bin/ghc-cabal\" configure libraries/unix dist-install \"\" --with-ghc=\"/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc-stage1\" --with-ghc-pkg=\"/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc-pkg\" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour=\"/usr/local/bin/HsColour\" --configure-option=CFLAGS=\"-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline\" --configure-option=LDFLAGS=\" \" --configure-option=CPPFLAGS=\" \" --gcc-options=\"-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline \" --configure-option=--with-iconv-includes=\"/usr/local/include\" --configure-option=--with-iconv-libraries=\"/usr/local/lib\" --configure-option=--with-gmp-includes=\"/usr/local/include\" --configure-option=--with-gmp-libraries=\"/usr/local/lib\" --with-gcc=\"/usr/local/bin/gcc48\" --with-ld=\"/usr/local/bin/ld\" --configure-option=--with-cc=\"/usr/local/bin/gcc48\" --with-ar=\"/usr/local/bin/ar\" --with-alex=\"/usr/local/bin/alex\" --with-happy=\"/usr/local/bin/happy\"\r\nConfiguring unix-2.7.1.0...\r\n[...]\r\nchecking for fdatasync... yes\r\n}}}\r\n\r\nThat is the corresponding part of the {{{config.log}}}:\r\n\r\n{{{\r\nconfigure:4242: checking for fdatasync\r\nconfigure:4263: /usr/local/bin/gcc48 -c -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5\r\nconftest.c: In function 'main':\r\nconftest.c:71:1: warning: implicit declaration of function 'fdatasync' [-Wimplicit-function-declaration]\r\n fdatasync(4);\r\n ^\r\nconfigure:4263: $? = 0\r\nconfigure:4271: result: yes\r\n}}}\r\n\r\nLooks like GCC is willing to compile the test code, although it notes that it cannot find the declaration of the {{{fdatasync()}}} function. Unfortunately, the {{{configure}}} script does not instruct GCC to do any linking or be serious on such warnings, so it happily proceeds.\r\n\r\nFor the reference, previously the {{{config.log}}} said something like that instead:\r\n\r\n{{{\r\nconfigure:4230: checking for fdatasync\r\nconfigure:4230: /usr/local/bin/gcc48 -o conftest -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5\r\n/tmp//ccDCjZtO.o: In function `main':\r\nconftest.c:(.text+0xa): undefined reference to `fdatasync'\r\ncollect2: error: ld returned 1 exit status\r\nconfigure:4230: $? = 1\r\n[...]\r\n}}}\r\n\r\nI am inclined to think that this is caused by the commit [https://github.com/haskell/unix/commit/b06446edd4753f964a46d27ddae864fad97adc13 b06446edd4753f964a46d27ddae864fad97adc13] for the {{{unix}}} package. Perhaps the following change can fix that, at least it fixed for me:\r\n\r\n{{{\r\n--- a/mk/warnings.mk\r\n+++ b/mk/warnings.mk\r\n@@ -16,6 +16,7 @@ SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable\r\n endif\r\n # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined\r\n SRC_CC_WARNING_OPTS += -Wno-error=inline\r\n+SRC_CC_WARNING_OPTS += -Werror=implicit-function-declaration\r\n endif\r\n \r\n else\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/8859import conditionalization in System.Posix.Files.Common is wrong2019-07-07T18:43:04Zrwbartonimport conditionalization in System.Posix.Files.Common is wrong`System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid "unused import" compiler warnings:
```
#if defined(HAVE_STRUCT_STAT_ST_CTIM) || \
defined(HAVE_STRUCT_STAT_ST_MTIM) || \
defined(HAVE_ST...`System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid "unused import" compiler warnings:
```
#if defined(HAVE_STRUCT_STAT_ST_CTIM) || \
defined(HAVE_STRUCT_STAT_ST_MTIM) || \
defined(HAVE_STRUCT_STAT_ST_ATIM) || \
defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \
defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \
defined(HAVE_STRUCT_STAT_ST_CTIMESPEC)
import Data.Int
import Data.Ratio
#endif
```
but those modules are actually used in functions like
```
accessTimeHiRes (FileStatus stat) =
unsafePerformIO $ withForeignPtr stat $ \stat_ptr -> do
sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime
#ifdef HAVE_STRUCT_STAT_ST_ATIM
nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIMESPEC
nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIMENSEC
nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIME_N
nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_UATIME
usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int)
let frac = toInteger usec % 10^(6::Int)
#else
let frac = 0
#endif
return $ fromRational $ toRational sec + frac
```
so there should be additional tests for `defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)`, `defined(HAVE_STRUCT_STAT_ST_ATIME_N)`, ... (15 total).
Or, maybe there's a better alternative, since this is very long-winded and fragile...
This breaks the build on Android, which has `st_atimensec`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"import conditionalization in System.Posix.Files.Common is wrong","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid \"unused import\" compiler warnings:\r\n\r\n{{{\r\n#if defined(HAVE_STRUCT_STAT_ST_CTIM) || \\\r\n defined(HAVE_STRUCT_STAT_ST_MTIM) || \\\r\n defined(HAVE_STRUCT_STAT_ST_ATIM) || \\\r\n defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \\\r\n defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \\\r\n defined(HAVE_STRUCT_STAT_ST_CTIMESPEC)\r\nimport Data.Int\r\nimport Data.Ratio\r\n#endif\r\n}}}\r\n\r\nbut those modules are actually used in functions like\r\n\r\n{{{\r\naccessTimeHiRes (FileStatus stat) =\r\n unsafePerformIO $ withForeignPtr stat $ \\stat_ptr -> do\r\n sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime\r\n#ifdef HAVE_STRUCT_STAT_ST_ATIM\r\n nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long)\r\n let frac = toInteger nsec % 10^(9::Int)\r\n#elif HAVE_STRUCT_STAT_ST_ATIMESPEC\r\n nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long)\r\n let frac = toInteger nsec % 10^(9::Int)\r\n#elif HAVE_STRUCT_STAT_ST_ATIMENSEC\r\n nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long)\r\n let frac = toInteger nsec % 10^(9::Int)\r\n#elif HAVE_STRUCT_STAT_ST_ATIME_N\r\n nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int)\r\n let frac = toInteger nsec % 10^(9::Int)\r\n#elif HAVE_STRUCT_STAT_ST_UATIME\r\n usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int)\r\n let frac = toInteger usec % 10^(6::Int)\r\n#else\r\n let frac = 0\r\n#endif\r\n return $ fromRational $ toRational sec + frac\r\n}}}\r\n\r\nso there should be additional tests for `defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)`, `defined(HAVE_STRUCT_STAT_ST_ATIME_N)`, ... (15 total).\r\n\r\nOr, maybe there's a better alternative, since this is very long-winded and fragile...\r\n\r\nThis breaks the build on Android, which has `st_atimensec`.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/3980System.Posix.Signals should provide a way to set the SA_NOCLDWAIT flag2019-07-07T19:01:16ZTomáš JanoušekSystem.Posix.Signals should provide a way to set the SA_NOCLDWAIT flagSince FreeBSD and OpenBSD don't conform to POSIX.1-2001 regarding the creation of zombie processes, “installHandler sigCHLD Ignore Nothing” just isn't enough to stop zombies from piling up. They do, however, support the SA_NOCLDWAIT flag...Since FreeBSD and OpenBSD don't conform to POSIX.1-2001 regarding the creation of zombie processes, “installHandler sigCHLD Ignore Nothing” just isn't enough to stop zombies from piling up. They do, however, support the SA_NOCLDWAIT flag to sigaction, and an interface for it would be useful to have.
The motivation is this: http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/9780
More info: http://en.wikipedia.org/wiki/SIGCHLD
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Posix.Signals should provide a way to set the SA_NOCLDWAIT flag","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Since FreeBSD and OpenBSD don't conform to POSIX.1-2001 regarding the creation of zombie processes, “installHandler sigCHLD Ignore Nothing” just isn't enough to stop zombies from piling up. They do, however, support the SA_NOCLDWAIT flag to sigaction, and an interface for it would be useful to have.\r\n\r\nThe motivation is this: http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/9780\r\nMore info: http://en.wikipedia.org/wiki/SIGCHLD","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/5063unix package has untracked dependency on libbsd2019-07-07T18:57:03Zduncanunix package has untracked dependency on libbsdSee ticket #4974 about unix-compat failing to build.
That is just a symptom. The real problem is that the unix package installs a HsUnix.h file which is broken on some target platforms, standard linux platforms.
HsUnix.h contains:
```...See ticket #4974 about unix-compat failing to build.
That is just a symptom. The real problem is that the unix package installs a HsUnix.h file which is broken on some target platforms, standard linux platforms.
HsUnix.h contains:
```
#ifdef HAVE_LIBUTIL_H
#include <libutil.h>
#endif
```
If the system that the package is built on has libbsd installed then it'll use it. But if the target system does not have this C lib then the HsUnix.h header is broken on such systems.
Why does the unix package optionally depend on libbsd? Is it really needed?
If it is needed then the distro packages need to be modified so that the unix package has dependency on libbsd-dev.
This raises another issue: we should be able to check that all the headers we install on a target actually work on that target. This check should be run as part of the ghc and HP release testing process.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unix package has untracked dependency on libbsd","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"See ticket #4974 about unix-compat failing to build.\r\n\r\nThat is just a symptom. The real problem is that the unix package installs a HsUnix.h file which is broken on some target platforms, standard linux platforms.\r\n\r\nHsUnix.h contains:\r\n{{{\r\n#ifdef HAVE_LIBUTIL_H\r\n#include <libutil.h>\r\n#endif\r\n}}}\r\n\r\nIf the system that the package is built on has libbsd installed then it'll use it. But if the target system does not have this C lib then the HsUnix.h header is broken on such systems.\r\n\r\nWhy does the unix package optionally depend on libbsd? Is it really needed?\r\n\r\nIf it is needed then the distro packages need to be modified so that the unix package has dependency on libbsd-dev.\r\n\r\nThis raises another issue: we should be able to check that all the headers we install on a target actually work on that target. This check should be run as part of the ghc and HP release testing process.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/24240Bump filepath to 1.4.200.1 and unix to 2.8.4.02024-02-08T17:32:03ZMatthew PickeringBump filepath to 1.4.200.1 and unix to 2.8.4.0The maintainer of filepath and unix has requested a bump of these libraries.
https://gitlab.haskell.org/ghc/ghc/-/issues/24017#note_537687The maintainer of filepath and unix has requested a bump of these libraries.
https://gitlab.haskell.org/ghc/ghc/-/issues/24017#note_5376879.6.4Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/7359unix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)2019-07-07T18:50:06ZAndreasVoellmyunix-2.6.0.0 fails to install on mac os x with 7.4.* (works with 7.6.1)Some package I am trying to build with cabal causes cabal to try to install unix-2.6.0.0 . This fails with the following errors:
```
[35 of 38] Compiling System.Posix.Signals ( dist/build/System/Posix/Signals.hs, dist/build/System/Posix...Some package I am trying to build with cabal causes cabal to try to install unix-2.6.0.0 . This fails with the following errors:
```
[35 of 38] Compiling System.Posix.Signals ( dist/build/System/Posix/Signals.hs, dist/build/System/Posix/Signals.o )
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUw_sigismember’:
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:8:0:
warning: dereferencing ‘void *’ pointer
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:8:0:
error: void value not ignored as it ought to be
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUF_sigfillset’:
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:10:0:
warning: dereferencing ‘void *’ pointer
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:10:0:
error: invalid use of void expression
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUR_sigdelset’:
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:12:0:
warning: dereferencing ‘void *’ pointer
/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:12:0:
error: invalid use of void expression
Failed to install unix-2.6.0.0
```
This seems to be a recent problem for me, so it may be due to some software updates for mac os x. I am running os x version 10.8.2 build 12c60. I have XCode version 4.5.1 with the "Command Line Tools" installed. I installed ghc from the haskell-platform after updating the os x and xcode (and command line tools).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unix-2.6.0.0 fails to install on mac os x","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Some package I am trying to build with cabal causes cabal to try to install unix-2.6.0.0 . This fails with the following errors: \r\n\r\n\r\n{{{\r\n[35 of 38] Compiling System.Posix.Signals ( dist/build/System/Posix/Signals.hs, dist/build/System/Posix/Signals.o )\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUw_sigismember’:\r\n\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:8:0:\r\n warning: dereferencing ‘void *’ pointer\r\n\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:8:0:\r\n error: void value not ignored as it ought to be\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUF_sigfillset’:\r\n\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:10:0:\r\n warning: dereferencing ‘void *’ pointer\r\n\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:10:0:\r\n error: invalid use of void expression\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c: In function ‘ghc_wrapper_dtUR_sigdelset’:\r\n\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:12:0:\r\n warning: dereferencing ‘void *’ pointer\r\n\r\n/var/folders/_c/4n2x0zfx7mx5gk_46pdxn3pm0000gn/T/ghc30459_0/ghc30459_0.c:12:0:\r\n error: invalid use of void expression\r\nFailed to install unix-2.6.0.0\r\n}}}\r\n\r\nThis seems to be a recent problem for me, so it may be due to some software updates for mac os x. I am running os x version 10.8.2 build 12c60. I have XCode version 4.5.1 with the \"Command Line Tools\" installed. I installed ghc from the haskell-platform after updating the os x and xcode (and command line tools). ","type_of_failure":"OtherFailure","blocking":[]} -->7.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/6160support sub-second resolutions for file timestamps2019-07-07T18:51:53Zrednebsupport sub-second resolutions for file timestampsCurrently all file timestamps related functions (accessTime, modificationTime, statusChangeTime, setFileTimes) offer resolution of one second. Most modern posix systems support better resolutions for file timestamps.
<details><summary>T...Currently all file timestamps related functions (accessTime, modificationTime, statusChangeTime, setFileTimes) offer resolution of one second. Most modern posix systems support better resolutions for file timestamps.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"support sub-second resolutions for file timestamps","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently all file timestamps related functions (accessTime, modificationTime, statusChangeTime, setFileTimes) offer resolution of one second. Most modern posix systems support better resolutions for file timestamps.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/5946getAnyProcessStatus signals an exception2019-07-07T18:52:53ZtocgetAnyProcessStatus signals an exceptionSteps to reproduce:
```
$ ghci-7.0.4
Prelude> import System.Posix
Prelude System.Posix> getAnyProcessStatus False False
```
Expected result:
```
Nothing
```
Actual result:
```
*** Exception: getGroupProcessStatus: does not exist (No...Steps to reproduce:
```
$ ghci-7.0.4
Prelude> import System.Posix
Prelude System.Posix> getAnyProcessStatus False False
```
Expected result:
```
Nothing
```
Actual result:
```
*** Exception: getGroupProcessStatus: does not exist (No child processes)
```
Tested on 6.12.1 and 7.0.4, Mac OS X 10.7 and Ubuntu 10.04.4 LTS.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getAnyProcessStatus signals an exception","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce:\r\n\r\n{{{\r\n$ ghci-7.0.4\r\nPrelude> import System.Posix\r\nPrelude System.Posix> getAnyProcessStatus False False\r\n}}}\r\n\r\nExpected result:\r\n{{{\r\nNothing\r\n}}}\r\n\r\nActual result:\r\n{{{\r\n*** Exception: getGroupProcessStatus: does not exist (No child processes)\r\n}}}\r\n\r\nTested on 6.12.1 and 7.0.4, Mac OS X 10.7 and Ubuntu 10.04.4 LTS.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5648System.Posix.Env should have a binding for clearenv2019-07-07T18:54:12ZIan Lynagh <igloo@earth.li>System.Posix.Env should have a binding for clearenv`System.Posix.Env` should have a binding for `clearenv`.
Test `posix005` relies on this functionality.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
|...`System.Posix.Env` should have a binding for `clearenv`.
Test `posix005` relies on this functionality.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Posix.Env should have a binding for clearenv","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"7.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"`System.Posix.Env` should have a binding for `clearenv`.\r\n\r\nTest `posix005` relies on this functionality.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/5319MacOS X + executeFile + -threaded = "Operation not supported"2019-07-07T18:55:54ZPHOMacOS X + executeFile + -threaded = "Operation not supported"http://uninformed.org/index.cgi?v=1&a=1&p=16
http://lists.apple.com/archives/cocoa-dev/2005/Oct/msg00836.html
Mac OS X has an undocumented behavior concerning 'execve(2)' inside a
threaded process. If a process tries to call 'execve(2)'...http://uninformed.org/index.cgi?v=1&a=1&p=16
http://lists.apple.com/archives/cocoa-dev/2005/Oct/msg00836.html
Mac OS X has an undocumented behavior concerning 'execve(2)' inside a
threaded process. If a process tries to call 'execve(2)' and has more
than one native thread, the kernel returns 'EOPNOTSUPP'. This prevents
'executeFile' from working when the threaded runtime is used.
```
% ghci
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> System.Posix.Process.executeFile "/bin/sh" False [] Nothing
Loading package unix-2.4.2.0 ... linking ... done.
*** Exception: /bin/sh: executeFile: failed (Operation not supported)
Prelude>
Leaving GHCi.
% uname
Darwin
```
To work around this, we have to 'fork(2)' before calling 'execve(2)',
to make sure there is only a single active thread.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MacOS X + executeFile + -threaded = \"Operation not supported\"","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["exec","thread,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"http://uninformed.org/index.cgi?v=1&a=1&p=16\r\nhttp://lists.apple.com/archives/cocoa-dev/2005/Oct/msg00836.html\r\n\r\nMac OS X has an undocumented behavior concerning 'execve(2)' inside a\r\nthreaded process. If a process tries to call 'execve(2)' and has more\r\nthan one native thread, the kernel returns 'EOPNOTSUPP'. This prevents\r\n'executeFile' from working when the threaded runtime is used.\r\n\r\n{{{\r\n% ghci\r\nGHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nPrelude> System.Posix.Process.executeFile \"/bin/sh\" False [] Nothing\r\nLoading package unix-2.4.2.0 ... linking ... done.\r\n*** Exception: /bin/sh: executeFile: failed (Operation not supported)\r\nPrelude> \r\nLeaving GHCi.\r\n% uname\r\nDarwin\r\n}}}\r\n\r\nTo work around this, we have to 'fork(2)' before calling 'execve(2)',\r\nto make sure there is only a single active thread.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/5222Typos in future POSIX process group API implementation2019-07-07T18:56:22ZFavoniaTypos in future POSIX process group API implementationThis patch should fix several typos in the implementation of future POSIX process group API. (See #5167 for more information about the new API.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --...This patch should fix several typos in the implementation of future POSIX process group API. (See #5167 for more information about the new API.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typos in future POSIX process group API implementation","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"Favonia"},"version":"7.0.3","keywords":["group","process"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This patch should fix several typos in the implementation of future POSIX process group API. (See #5167 for more information about the new API.)","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5184createDirectory does not retry on EINTR (interrupted)2019-07-07T18:56:31ZCoreyOConnorcreateDirectory does not retry on EINTR (interrupted)With GHC 7.0.3 on Mac OS X 32bit the createDirectory call does not retry if the call is interrupted. I would expect the call to be retried.
Unfortunately, I have not determined a small test program for this bug.
This is the output from ...With GHC 7.0.3 on Mac OS X 32bit the createDirectory call does not retry if the call is interrupted. I would expect the call to be retried.
Unfortunately, I have not determined a small test program for this bug.
This is the output from when this issue occurs:
```
/home/coconnor/Development/dev-system: createDirectory: interrupted (Interrupted system call)
```
Interestingly the directory indicated by this output does not match the directory requested to be created. The program calls:
```
createDirectoryIfMissing True "/home/coconnor/Development/dev-system/build/"
```
And it is known, at the time, that the directory "/home/coconnor/Development/dev-system" exists. Perhaps the method checking for if a directory exists is also receiving EINTR?
This same program works as expected on linux 32bit & 64bit using GHC 7.0.3.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"createDirectory does not retry on EINTR (interrupted)","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With GHC 7.0.3 on Mac OS X 32bit the createDirectory call does not retry if the call is interrupted. I would expect the call to be retried.\r\n\r\nUnfortunately, I have not determined a small test program for this bug. \r\nThis is the output from when this issue occurs:\r\n{{{\r\n/home/coconnor/Development/dev-system: createDirectory: interrupted (Interrupted system call)\r\n}}}\r\n\r\nInterestingly the directory indicated by this output does not match the directory requested to be created. The program calls:\r\n\r\n{{{\r\ncreateDirectoryIfMissing True \"/home/coconnor/Development/dev-system/build/\"\r\n}}}\r\n\r\nAnd it is known, at the time, that the directory \"/home/coconnor/Development/dev-system\" exists. Perhaps the method checking for if a directory exists is also receiving EINTR?\r\n\r\nThis same program works as expected on linux 32bit & 64bit using GHC 7.0.3. \r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlow