GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:49:45Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7431execvpe exists on QNX2019-07-07T18:49:45Zsingpolymaexecvpe exists on QNXThe definition of `execvpe` in this package conflicts with the native QNX definition: http://www.qnx.com/developers/docs/6.3.2/neutrino/lib_ref/e/execvpe.html
For now I have just put `#ifndef __QNXNTO__` around it in the header file and...The definition of `execvpe` in this package conflicts with the native QNX definition: http://www.qnx.com/developers/docs/6.3.2/neutrino/lib_ref/e/execvpe.html
For now I have just put `#ifndef __QNXNTO__` around it in the header file and the c file.
<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":"execvpe exists on QNX","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The definition of `execvpe` in this package conflicts with the native QNX definition: http://www.qnx.com/developers/docs/6.3.2/neutrino/lib_ref/e/execvpe.html\r\n\r\nFor now I have just put `#ifndef __QNXNTO__` around it in the header file and the c file.","type_of_failure":"OtherFailure","blocking":[]} -->https://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/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/7345unix-2.6.0.0 does not provide access to st_blksize and st_blocks2019-07-07T18:50:09ZJohnWiegleyunix-2.6.0.0 does not provide access to st_blksize and st_blocksThere is currently no clear way in Haskell to determine how much disk space a file actually occupies on disk -- only it's apparent byte size. Case in point, the popular git-annex tool has had to rely on a hack because there is no way to ...There is currently no clear way in Haskell to determine how much disk space a file actually occupies on disk -- only it's apparent byte size. Case in point, the popular git-annex tool has had to rely on a hack because there is no way to get at the st_blocks information in the POSIX stat record.
I recommend adding two functions to Common.hsc in unix, which are in the attached patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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 does not provide access to st_blksize and st_blocks","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is currently no clear way in Haskell to determine how much disk space a file actually occupies on disk -- only it's apparent byte size. Case in point, the popular git-annex tool has had to rely on a hack because there is no way to get at the st_blocks information in the POSIX stat record.\r\n\r\nI recommend adding two functions to Common.hsc in unix, which are in the attached patch.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7343Potential build issues on some UNIX versions2019-07-07T18:50:10ZSimon Hengelsol@typeful.netPotential build issues on some UNIX versionsIn `HsUnix.c` `unsetenv` is used even if `HAVE_UNSETENV` is not defined. It's probably not a big deal as it has been like that for four years.
But AFAIK, this would at least fail to build with relatively recent versions of HPUX.
If we ...In `HsUnix.c` `unsetenv` is used even if `HAVE_UNSETENV` is not defined. It's probably not a big deal as it has been like that for four years.
But AFAIK, this would at least fail to build with relatively recent versions of HPUX.
If we conclude that this check is not necessary, then I would remove them from `System.Posix.Env`, too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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":"Potential build issues on some UNIX versions","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In {{{HsUnix.c}}} {{{unsetenv}}} is used even if {{{HAVE_UNSETENV}}} is not defined. It's probably not a big deal as it has been like that for four years.\r\n\r\nBut AFAIK, this would at least fail to build with relatively recent versions of HPUX.\r\n\r\nIf we conclude that this check is not necessary, then I would remove them from {{{System.Posix.Env}}}, too.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7342Memory violation bug in System.Posix.Env.putEnv2019-07-07T18:50:10ZSimon Hengelsol@typeful.netMemory violation bug in System.Posix.Env.putEnv`putEnv` frees the marshaled string after calling `c_putenv`. This leads to unpredictable behavior, as the string becomes part of the environment and should not be freed.
See [SUSv2](http://pubs.opengroup.org/onlinepubs/007908799/xsh/pu...`putEnv` frees the marshaled string after calling `c_putenv`. This leads to unpredictable behavior, as the string becomes part of the environment and should not be freed.
See [SUSv2](http://pubs.opengroup.org/onlinepubs/007908799/xsh/putenv.html):
> 1. .. the string pointed to by string shall become part of the
>
> environment ...
The issue is reproducible with the following QC property:
```
import Test.QuickCheck
import Test.QuickCheck.Property
import System.Posix.Env
import Data.IORef
import qualified Data.Map as Map
import Control.Applicative
isValidKey :: String -> Bool
isValidKey k = '\NUL' `notElem` k && '=' `notElem` k && (not . null) k
isValidValue :: String -> Bool
isValidValue v = '\NUL' `notElem` v && (not . null) v
main :: IO ()
main = do
env' <- getEnvironment >>= newIORef . Map.fromList
quickCheck $ \k v -> isValidKey k ==> isValidValue v ==> morallyDubiousIOProperty $ do
putEnv (k ++ "=" ++ v)
modifyIORef env' (Map.insert k v)
(==) <$> readIORef env' <*> (Map.fromList <$> getEnvironment)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.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":"Bug in System.Posix.Env.putEnv","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":"Bug","description":"{{{putEnv}}} frees the marshaled string after calling {{{c_putenv}}}. This leads to unpredictable behavior, as the string becomes part of the environment and should not be freed.\r\n\r\nSee [http://pubs.opengroup.org/onlinepubs/007908799/xsh/putenv.html SUSv2]:\r\n\r\n> ... the string pointed to by string shall become part of the\r\n> environment ...\r\n\r\nThe issue is reproducible with the following QC property:\r\n\r\n{{{\r\nimport Test.QuickCheck\r\nimport Test.QuickCheck.Property\r\nimport System.Posix.Env\r\nimport Data.IORef\r\nimport qualified Data.Map as Map\r\nimport Control.Applicative\r\n\r\nisValidKey :: String -> Bool\r\nisValidKey k = '\\NUL' `notElem` k && '=' `notElem` k && (not . null) k\r\n\r\nisValidValue :: String -> Bool\r\nisValidValue v = '\\NUL' `notElem` v && (not . null) v\r\n\r\nmain :: IO ()\r\nmain = do\r\n env' <- getEnvironment >>= newIORef . Map.fromList\r\n quickCheck $ \\k v -> isValidKey k ==> isValidValue v ==> morallyDubiousIOProperty $ do\r\n putEnv (k ++ \"=\" ++ v)\r\n modifyIORef env' (Map.insert k v)\r\n (==) <$> readIORef env' <*> (Map.fromList <$> getEnvironment)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://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/6053packages in GHC should have different versions from hackage if the packages d...2019-07-07T18:52:24ZLemmingpackages in GHC should have different versions from hackage if the packages differI try to compile a package with many dependencies using GHC-7.5.20120426 in order to check whether #5970 is resolved. This turns out to be difficult because this temporary GHC version seems to use packages with the same version as their ...I try to compile a package with many dependencies using GHC-7.5.20120426 in order to check whether #5970 is resolved. This turns out to be difficult because this temporary GHC version seems to use packages with the same version as their counterparts on Hackage but different content.
For example GHC-7.5.20120426 is bundled with unix-2.5.1.0 and bytestring-0.10.0.0. However the unix-2.5.1.0 on Hackage excludes bytestring-0.10.0.0. Thus cabal-install refuses to install something that depends on unix-2.5.1.0.
Another example: Both GHC-7.4.1 and GHC-7.5.20120426 are bundled with base-4.5.0.0. However in GHC-7.5, Num is no longer superclass of Bits. I think such a change requires a version bump to base-4.6.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.5 |
| 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":"packages in GHC should have different versions from hackage if the packages differ","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I try to compile a package with many dependencies using GHC-7.5.20120426 in order to check whether #5970 is resolved. This turns out to be difficult because this temporary GHC version seems to use packages with the same version as their counterparts on Hackage but different content.\r\n\r\nFor example GHC-7.5.20120426 is bundled with unix-2.5.1.0 and bytestring-0.10.0.0. However the unix-2.5.1.0 on Hackage excludes bytestring-0.10.0.0. Thus cabal-install refuses to install something that depends on unix-2.5.1.0.\r\n\r\nAnother example: Both GHC-7.4.1 and GHC-7.5.20120426 are bundled with base-4.5.0.0. However in GHC-7.5, Num is no longer superclass of Bits. I think such a change requires a version bump to base-4.6.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://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/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/5738System.Posix.Temp mkstemp bugs and addition of mkdtem2019-07-07T18:53:49ZdeianSystem.Posix.Temp mkstemp bugs and addition of mkdtemThe description of mkstemp and GHC/Hugs and non-GHC/Hugs code disagree (on requiring the user to provide a valid template). Attached is a patch which fixes this for Temp and Temp.ByteString.
Additionally, I would create another ticket wi...The description of mkstemp and GHC/Hugs and non-GHC/Hugs code disagree (on requiring the user to provide a valid template). Attached is a patch which fixes this for Temp and Temp.ByteString.
Additionally, I would create another ticket with a feature request for this, but since the patch provides the implementation I'll include it here: addition of mkdtemp. (I would very much appreciate it this or some other of mkdtemp can be included in the next release!)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"System.Posix.Temp mkstemp bugs and addition of mkdtem","status":"New","operating_system":"Unknown/Multiple","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"The description of mkstemp and GHC/Hugs and non-GHC/Hugs code disagree (on requiring the user to provide a valid template). Attached is a patch which fixes this for Temp and Temp.ByteString.\r\nAdditionally, I would create another ticket with a feature request for this, but since the patch provides the implementation I'll include it here: addition of mkdtemp. (I would very much appreciate it this or some other of mkdtemp can be included in the next release!)","type_of_failure":"OtherFailure","blocking":[]} -->dtereidtereihttps://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/5504Inconsistent sizes for struct rlimit2019-07-07T18:54:58Zdaniel.is.fischerInconsistent sizes for struct rlimitOn my 32-bit system, I find
```
/* Define to Haskell type for rlim_t */
#define HTYPE_RLIM_T Word64
```
in `HsBaseConfig.h`. gcc says sizeof(rlim_t) = 4 and thus sizeof(struct rlimit) = 8.
Previously (7.0 and before), `get/setResource...On my 32-bit system, I find
```
/* Define to Haskell type for rlim_t */
#define HTYPE_RLIM_T Word64
```
in `HsBaseConfig.h`. gcc says sizeof(rlim_t) = 4 and thus sizeof(struct rlimit) = 8.
Previously (7.0 and before), `get/setResourceLimit` allocated a 16-byte buffer and wrote/read the hard limit at an 8-byte offset, consistent with `HsBaseConfig.h` (but not with sys/resource.h), and apparently it worked (test resourceLimit used to pass and getting the limits returned the previously set values in a few tests for various resources).
Now they allocate 8 bytes and read/write the hard limit at a 4-byte offset, consistent with `sys/resource.h`, but inconsistent with `HsBaseConfig.h`, and resourceLimit fails, the same tests as above always returned `ResourceLimit (2^64-1)` for both, soft and hard limits. (The compiled ways of resourceLimit fail with invalid argument on setting.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.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":"Inconsistent sizes for struct rlimit","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On my 32-bit system, I find\r\n{{{\r\n/* Define to Haskell type for rlim_t */\r\n#define HTYPE_RLIM_T Word64\r\n}}}\r\nin `HsBaseConfig.h`. gcc says sizeof(rlim_t) = 4 and thus sizeof(struct rlimit) = 8.\r\n\r\nPreviously (7.0 and before), `get/setResourceLimit` allocated a 16-byte buffer and wrote/read the hard limit at an 8-byte offset, consistent with `HsBaseConfig.h` (but not with sys/resource.h), and apparently it worked (test resourceLimit used to pass and getting the limits returned the previously set values in a few tests for various resources).\r\n\r\nNow they allocate 8 bytes and read/write the hard limit at a 4-byte offset, consistent with `sys/resource.h`, but inconsistent with `HsBaseConfig.h`, and resourceLimit fails, the same tests as above always returned `ResourceLimit (2^64-1)` for both, soft and hard limits. (The compiled ways of resourceLimit fail with invalid argument on setting.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5482isSymbolicLink doesn't work2019-07-07T18:55:05ZDmitryBespalovisSymbolicLink doesn't workThis function from System.Posix.Files (unix-2.5.0.0) always returns False for symlinks on my linux os (2.6.39-gentoo-r3). GHC version 7.0.4. What's wrong?
<details><summary>Trac metadata</summary>
| Trac field | Value ...This function from System.Posix.Files (unix-2.5.0.0) always returns False for symlinks on my linux os (2.6.39-gentoo-r3). GHC version 7.0.4. What's wrong?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.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":"isSymbolicLink doesn't work","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":["isSymbolicLink"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This function from System.Posix.Files (unix-2.5.0.0) always returns False for symlinks on my linux os (2.6.39-gentoo-r3). GHC version 7.0.4. What's wrong?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5383GetOpt parser too strict2019-07-07T18:55:39ZmcandreGetOpt parser too strictFor !GetOpt, some CLI arguments must be right next to the flag, and some do not.
Relevant scripts: [http://www.delicious.com/mcandre/getoptfu](http://www.delicious.com/mcandre/getoptfu)
The command specified two bananas, but the 2 isn'...For !GetOpt, some CLI arguments must be right next to the flag, and some do not.
Relevant scripts: [http://www.delicious.com/mcandre/getoptfu](http://www.delicious.com/mcandre/getoptfu)
The command specified two bananas, but the 2 isn't parsed correctly.
```
$ ./groceries.hs -p -j -b 2
FoodCo welcomes you, Mr. Derp.
YOU BOUGHT PEANUT BUTTER!!!
YOU BOUGHT JELLY!!!
YOU BOUGHT 1 BANANAS!!!
Mr. Derp bought 3 items.
Thank you, come again soon.
```
When 2 is specified right after `-b`, it is parsed correctly. This is against most CLI formats. Most CLI users expect a space between flags and values.
```
$ ./groceries.hs -p -j -b2
FoodCo welcomes you, Mr. Derp.
YOU BOUGHT PEANUT BUTTER!!!
YOU BOUGHT JELLY!!!
YOU BOUGHT 2 BANANAS!!!
Mr. Derp bought 4 items.
Thank you, come again soon.
```
Furthermore, !GetOpt is inconsistent: it does not need a space between flags and string values--it parses them either way.
```
$ ./groceries.hs -s Moops
Moops welcomes you, Mr. Derp.
Mr. Derp bought 0 items.
Thank you, come again soon.
$ ./groceries.hs -sMoops
Moops welcomes you, Mr. Derp.
Mr. Derp bought 0 items.
Thank you, come again soon.
```
<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":"GetOpt parser too strict","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":"For !GetOpt, some CLI arguments must be right next to the flag, and some do not.\r\n\r\nRelevant scripts: [http://www.delicious.com/mcandre/getoptfu]\r\n\r\nThe command specified two bananas, but the 2 isn't parsed correctly.\r\n\r\n{{{\r\n$ ./groceries.hs -p -j -b 2\r\nFoodCo welcomes you, Mr. Derp.\r\nYOU BOUGHT PEANUT BUTTER!!!\r\nYOU BOUGHT JELLY!!!\r\nYOU BOUGHT 1 BANANAS!!!\r\nMr. Derp bought 3 items.\r\nThank you, come again soon.\r\n}}}\r\n\r\nWhen 2 is specified right after {{{-b}}}, it is parsed correctly. This is against most CLI formats. Most CLI users expect a space between flags and values.\r\n\r\n{{{\r\n$ ./groceries.hs -p -j -b2\r\nFoodCo welcomes you, Mr. Derp.\r\nYOU BOUGHT PEANUT BUTTER!!!\r\nYOU BOUGHT JELLY!!!\r\nYOU BOUGHT 2 BANANAS!!!\r\nMr. Derp bought 4 items.\r\nThank you, come again soon.\r\n}}}\r\n\r\nFurthermore, !GetOpt is inconsistent: it does not need a space between flags and string values--it parses them either way.\r\n\r\n{{{\r\n$ ./groceries.hs -s Moops\r\nMoops welcomes you, Mr. Derp.\r\nMr. Derp bought 0 items.\r\nThank you, come again soon.\r\n$ ./groceries.hs -sMoops\r\nMoops welcomes you, Mr. Derp.\r\nMr. Derp bought 0 items.\r\nThank you, come again soon.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://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 Marlowhttps://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/4523unix package does not check properly for sem_close2019-07-07T18:58:35Zbosunix package does not check properly for sem_closeOn modern Linux systems (in my case, Fedora 13 and 14), the `sem_close` and other functions are in the `rt` and `pthread` libraries. This combination is not checked for properly by the `unix` package's `autoconf` script. As a result atte...On modern Linux systems (in my case, Fedora 13 and 14), the `sem_close` and other functions are in the `rt` and `pthread` libraries. This combination is not checked for properly by the `unix` package's `autoconf` script. As a result attempting to build the `unix` package will succeed, but linking applications against the misconfigured `unix` will result in undefined symbol errors for e.g. `sem_close`.
I believe that the C compiler needs to be invoked with `-pthread` for the right thing to happen, as `unix.buildinfo` contains a reference to `rt` that is nevertheless not enough:
```
buildable: True
cc-options:
ld-options:
extra-libraries: rt util dl
```
Here's my current workaround hack:
```
--- old-unix/configure.ac 2010-11-23 15:25:33.741849630 -0800
+++ new-unix/configure.ac 2010-11-23 15:25:33.760849987 -0800
@@ -215,6 +215,9 @@
PTHREAD_CFLAGS=-pthread
PTHREAD_LDFLAGS=-pthread
;;
+linux*)
+ PTHREAD_LIBS=pthread
+ ;;
esac
AC_SUBST(PTHREAD_CFLAGS)
AC_SUBST(PTHREAD_LDFLAGS)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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 package does not check properly for sem_close","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On modern Linux systems (in my case, Fedora 13 and 14), the {{{sem_close}}} and other functions are in the {{{rt}}} and {{{pthread}}} libraries. This combination is not checked for properly by the {{{unix}}} package's {{{autoconf}}} script. As a result attempting to build the {{{unix}}} package will succeed, but linking applications against the misconfigured {{{unix}}} will result in undefined symbol errors for e.g. {{{sem_close}}}.\r\n\r\nI believe that the C compiler needs to be invoked with {{{-pthread}}} for the right thing to happen, as {{{unix.buildinfo}}} contains a reference to {{{rt}}} that is nevertheless not enough:\r\n\r\n{{{\r\n\r\nbuildable: True\r\ncc-options: \r\nld-options: \r\nextra-libraries: rt util dl \r\n}}}\r\n\r\nHere's my current workaround hack:\r\n\r\n{{{\r\n\r\n--- old-unix/configure.ac\t2010-11-23 15:25:33.741849630 -0800\r\n+++ new-unix/configure.ac\t2010-11-23 15:25:33.760849987 -0800\r\n@@ -215,6 +215,9 @@\r\n \tPTHREAD_CFLAGS=-pthread\r\n \tPTHREAD_LDFLAGS=-pthread\r\n \t;;\r\n+linux*)\r\n+\tPTHREAD_LIBS=pthread\r\n+\t;;\r\n esac\r\n AC_SUBST(PTHREAD_CFLAGS)\r\n AC_SUBST(PTHREAD_LDFLAGS)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>