GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:06:11Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2948the type of System.Posix.Process.executeFile is not general enough2019-07-07T19:06:11Znr@eecs.harvard.eduthe type of System.Posix.Process.executeFile is not general enoughBecause `System.Posix.Process.executeFile` does not return, its return type should be `IO a`, not `IO ()`. This change would make it possible to use `System.Posix.Process.executeFile` in a context that expects `IO Int` or `IO ProcessStat...Because `System.Posix.Process.executeFile` does not return, its return type should be `IO a`, not `IO ()`. This change would make it possible to use `System.Posix.Process.executeFile` in a context that expects `IO Int` or `IO ProcessStatus`, for example.
I may well have assigned this bug to the wrong library.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dias@cs.tufts.edu |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"the type of System.Posix.Process.executeFile is not general enough","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["dias@cs.tufts.edu"],"type":"Bug","description":"Because {{{System.Posix.Process.executeFile}}} does not return, its return type should be {{{IO a}}}, not {{{IO ()}}}. This change would make it possible to use {{{System.Posix.Process.executeFile}}} in a context that expects {{{IO Int}}} or {{{IO ProcessStatus}}}, for example.\r\n\r\nI may well have assigned this bug to the wrong library.","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3142unix-2.3.2.0 needs base >= 4.1 in .cabal file2019-07-07T19:05:10Zguestunix-2.3.2.0 needs base >= 4.1 in .cabal fileFrom the hackage log\[1\] we can see that unix-2.3.2.0 lacks the appropriate lower bound on the version of base (\>= 4.1) in build-depends.
\[1\]http://hackage.haskell.org/packages/archive/unix/2.3.2.0/logs/failure/ghc-6.10
<details><s...From the hackage log\[1\] we can see that unix-2.3.2.0 lacks the appropriate lower bound on the version of base (\>= 4.1) in build-depends.
\[1\]http://hackage.haskell.org/packages/archive/unix/2.3.2.0/logs/failure/ghc-6.10
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| 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.3.2.0 needs base >= 4.x in .cabal file","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"From the hackage log[1] we can see that unix-2.3.2.0 lacks the appropriate lower bound on the version of base (>= 4.1) in build-depends.\r\n\r\n[1]http://hackage.haskell.org/packages/archive/unix/2.3.2.0/logs/failure/ghc-6.10","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3178Fix linking -lpthread for semaphores2019-07-07T19:05:00ZsthibaulFix linking -lpthread for semaphoresHello,
On the GNU/Hurd OS, the posix semaphore library does not link because
of undefined reference to sem_\* functions. I do not know how the ghc
build process works, could it be that it forgets to use -lpthread for
that library?
Samu...Hello,
On the GNU/Hurd OS, the posix semaphore library does not link because
of undefined reference to sem_\* functions. I do not know how the ghc
build process works, could it be that it forgets to use -lpthread for
that library?
Samuel
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fix linking -lpthread for semaphores","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nOn the GNU/Hurd OS, the posix semaphore library does not link because\r\nof undefined reference to sem_* functions. I do not know how the ghc\r\nbuild process works, could it be that it forgets to use -lpthread for\r\nthat library?\r\n\r\nSamuel\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/3179Linking unix package fails2019-07-07T19:05:00ZeelcoLinking unix package failsI just built GHC 6.10.2 from scratch on a Debian 4.0 machine. Everything seems to go well. But, when 'cabal-install'ing happstack-data, I'll get the following error:
```
Loading package unix-2.3.2.0 ... <command line>: can't load .so/.D...I just built GHC 6.10.2 from scratch on a Debian 4.0 machine. Everything seems to go well. But, when 'cabal-install'ing happstack-data, I'll get the following error:
```
Loading package unix-2.3.2.0 ... <command line>: can't load .so/.DLL for:
rt (/usr/lib/librt.so: symbol __librt_multiple_threads, version GLIBC_PRIVATE
not defined in file libc.so.6 with link time reference)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Linking unix package fails","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I just built GHC 6.10.2 from scratch on a Debian 4.0 machine. Everything seems to go well. But, when 'cabal-install'ing happstack-data, I'll get the following error:\r\n\r\n{{{\r\nLoading package unix-2.3.2.0 ... <command line>: can't load .so/.DLL for: \r\nrt (/usr/lib/librt.so: symbol __librt_multiple_threads, version GLIBC_PRIVATE \r\nnot defined in file libc.so.6 with link time reference)\r\n\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/3218Proposal: System.Posix.fdReadBuf/fdWriteBuf2019-07-07T19:04:51ZSimon MarlowProposal: System.Posix.fdReadBuf/fdWriteBufFunctions for reading/writing actual arrays of bytes in memory. At the moment, `System.Posix` only provides
```
fdRead :: Fd
-> ByteCount -- ^How many bytes to read
-> IO (String, ByteCount) -- ^The bytes read, how many by...Functions for reading/writing actual arrays of bytes in memory. At the moment, `System.Posix` only provides
```
fdRead :: Fd
-> ByteCount -- ^How many bytes to read
-> IO (String, ByteCount) -- ^The bytes read, how many bytes were read.
fdWrite :: Fd -> String -> IO ByteCount
```
which are not only wrong (`String`?), but too slow for many purposes.
I propose
```
Mon May 11 16:21:02 BST 2009 Simon Marlow <marlowsd@gmail.com>
* add fdReadBuf, fdWriteBuf
-- | Read data from an 'Fd' into memory. This is exactly equivalent
-- to the POSIX @read@ function.
fdReadBuf :: Fd
-> Ptr Word8 -- ^ Memory in which to put the data
-> ByteCount -- ^ Maximum number of bytes to read
-> IO Bytecount -- ^ Number of bytes read (zero for EOF)
-- | Write data from memory to an 'Fd'. This is exactly equivalent
-- to the POSIX @write@ function.
fdWriteBuf :: Fd
-> Ptr Word8 -- ^ Memory containing the data to write
-> ByteCount -- ^ Maximum number of bytes to write
-> IO ByteCount -- ^ Number of bytes written
```
darcs patches are attached.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"Proposal: System.Posix.fdReadBuf/fdWriteBuf","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"Not GHC","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Functions for reading/writing actual arrays of bytes in memory. At the moment, `System.Posix` only provides\r\n\r\n{{{\r\nfdRead :: Fd\r\n -> ByteCount -- ^How many bytes to read\r\n -> IO (String, ByteCount) -- ^The bytes read, how many bytes were read.\r\n\r\nfdWrite :: Fd -> String -> IO ByteCount\r\n}}}\r\n\r\nwhich are not only wrong (`String`?), but too slow for many purposes.\r\n\r\nI propose\r\n\r\n{{{\r\nMon May 11 16:21:02 BST 2009 Simon Marlow <marlowsd@gmail.com>\r\n * add fdReadBuf, fdWriteBuf\r\n \r\n -- | Read data from an 'Fd' into memory. This is exactly equivalent\r\n -- to the POSIX @read@ function.\r\n fdReadBuf :: Fd\r\n -> Ptr Word8 -- ^ Memory in which to put the data\r\n -> ByteCount -- ^ Maximum number of bytes to read\r\n -> IO Bytecount -- ^ Number of bytes read (zero for EOF)\r\n \r\n -- | Write data from memory to an 'Fd'. This is exactly equivalent\r\n -- to the POSIX @write@ function.\r\n fdWriteBuf :: Fd\r\n -> Ptr Word8 -- ^ Memory containing the data to write\r\n -> ByteCount -- ^ Maximum number of bytes to write\r\n -> IO ByteCount -- ^ Number of bytes written\r\n}}}\r\n\r\ndarcs patches are attached.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Not GHCSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3473System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr2019-07-07T19:03:42ZKari PahulaSystem.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtrRunning this program
```
import System.Posix.Semaphore
main = do
s <- semOpen "c" (OpenSemFlags True False) 0666 1
semThreadWait s
v <- semGetValue s
putStrLn "Type!"
a <- getLine
putStrL...Running this program
```
import System.Posix.Semaphore
main = do
s <- semOpen "c" (OpenSemFlags True False) 0666 1
semThreadWait s
v <- semGetValue s
putStrLn "Type!"
a <- getLine
putStrLn $ "OK, " ++ a
semPost s
```
fails like this:
```
Type!
abc
OK, abc
sem: error: a C finalizer called back into Haskell.
This was previously allowed, but is disallowed in GHC 6.10.2 and later.
To create finalizers that may call back into Haskll, use
Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr.
```
The attached patch for libraries/unix/System/Posix/Semaphore.hsc should fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.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":"System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Running this program \r\n\r\n{{{\r\nimport System.Posix.Semaphore\r\n\r\nmain = do\r\n s <- semOpen \"c\" (OpenSemFlags True False) 0666 1\r\n semThreadWait s\r\n v <- semGetValue s\r\n putStrLn \"Type!\"\r\n a <- getLine\r\n putStrLn $ \"OK, \" ++ a\r\n semPost s\r\n}}}\r\n\r\nfails like this:\r\n\r\n{{{\r\nType!\r\nabc\r\nOK, abc\r\nsem: error: a C finalizer called back into Haskell.\r\nThis was previously allowed, but is disallowed in GHC 6.10.2 and later.\r\nTo create finalizers that may call back into Haskll, use\r\nForeign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr.\r\n}}}\r\n\r\nThe attached patch for libraries/unix/System/Posix/Semaphore.hsc should fix this.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/3723SharedMem.hsc should include <fcntl.h>, not <sys/fcntl.h>2019-07-07T19:02:35ZdonnSharedMem.hsc should include <fcntl.h>, not <sys/fcntl.h>libraries/unix/System/Posix/SharedMem.hsc should include \<fcntl.h\>, per POSIX 1003.1 I believe, not \<sys/fcntl.h\>
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------...libraries/unix/System/Posix/SharedMem.hsc should include \<fcntl.h\>, per POSIX 1003.1 I believe, not \<sys/fcntl.h\>
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Other |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"SharedMem.hsc should include <fcntl.h>, not <sys/fcntl.h>","status":"New","operating_system":"Other","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"libraries/unix/System/Posix/SharedMem.hsc should include <fcntl.h>, per POSIX 1003.1 I believe, not <sys/fcntl.h>","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3780unix-2.4.0.0 fails with base 4.12019-07-07T19:02:12Zduncanunix-2.4.0.0 fails with base 4.1The unix package states:
```
build-depends: base >=4.1 && <4.3
```
And while it does compile with base 4.1, using ghc-6.10, nothing can successfully link against it.
The symptoms are:
```
/usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-...The unix package states:
```
build-depends: base >=4.1 && <4.3
```
And while it does compile with base 4.1, using ghc-6.10, nothing can successfully link against it.
The symptoms are:
```
/usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_d_name':
(.text+0x1c0): multiple definition of `__hscore_d_name'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x0): first defined here
/usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_free_dirent':
(.text+0x4f0): multiple definition of `__hscore_free_dirent'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x10): first defined here
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk63_info':
(.text+0x30c4): undefined reference to `fcntl_read'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk6A_info':
(.text+0x31f0): undefined reference to `fcntl_write'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk8h_info':
(.text+0x36cc): undefined reference to `fcntl_read'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl4O_info':
(.text+0x3a52): undefined reference to `fcntl_lock'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl6S_info':
(.text+0x3cc2): undefined reference to `fcntl_lock'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl9I_info':
(.text+0x402a): undefined reference to `fcntl_lock'
```
There are two problems here, the duplicate `__hscore_*` symbols and and the missing `fcntl_*` symbols.
The `__hscore_d_name` C function really is duplicated. There is one copy in `base/include/HsBase.h` in ghc-6.10, there is another copy in `cbits/dirUtils.c` in unix-2.4.0.0. Clearly what has happened is that the function from base has been moved into the unix package. However that means when building the unix package with the older base then we get both. The solution is to rename the one in the unix package. Ideally we could limit the visibility of symbols somehow.
The `fcntl_read` are not defined in the unix package. They are defined in `HsBase.h` in ghc-6.12 but not in 6.10. Hence they are also missing when unix-2.4.0.0 is built against the older base. The solution is to define them locally.
Originally filed as Cabal ticket: http://hackage.haskell.org/trac/hackage/ticket/620
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.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.4.0.0 fails with base 4.1","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":"Bug","description":"The unix package states:\r\n{{{\r\nbuild-depends: base >=4.1 && <4.3\r\n}}}\r\n\r\nAnd while it does compile with base 4.1, using ghc-6.10, nothing can successfully link against it.\r\n\r\nThe symptoms are:\r\n{{{\r\n/usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_d_name':\r\n(.text+0x1c0): multiple definition of `__hscore_d_name'\r\n/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x0): first defined here\r\n/usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_free_dirent':\r\n(.text+0x4f0): multiple definition of `__hscore_free_dirent'\r\n/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x10): first defined here\r\n/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk63_info':\r\n(.text+0x30c4): undefined reference to `fcntl_read'\r\n/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk6A_info':\r\n(.text+0x31f0): undefined reference to `fcntl_write'\r\n/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk8h_info':\r\n(.text+0x36cc): undefined reference to `fcntl_read'\r\n/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl4O_info':\r\n(.text+0x3a52): undefined reference to `fcntl_lock'\r\n/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl6S_info':\r\n(.text+0x3cc2): undefined reference to `fcntl_lock'\r\n/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl9I_info':\r\n(.text+0x402a): undefined reference to `fcntl_lock'\r\n}}}\r\n\r\nThere are two problems here, the duplicate `__hscore_*` symbols and and the missing `fcntl_*` symbols.\r\n\r\nThe `__hscore_d_name` C function really is duplicated. There is one copy in `base/include/HsBase.h` in ghc-6.10, there is another copy in `cbits/dirUtils.c` in unix-2.4.0.0. Clearly what has happened is that the function from base has been moved into the unix package. However that means when building the unix package with the older base then we get both. The solution is to rename the one in the unix package. Ideally we could limit the visibility of symbols somehow.\r\n\r\nThe `fcntl_read` are not defined in the unix package. They are defined in `HsBase.h` in ghc-6.12 but not in 6.10. Hence they are also missing when unix-2.4.0.0 is built against the older base. The solution is to define them locally.\r\n\r\nOriginally filed as Cabal ticket: http://hackage.haskell.org/trac/hackage/ticket/620","type_of_failure":"OtherFailure","blocking":[]} -->6.12.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://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/4039problems with semaphores in ghc-6.10.4 unix-2.3.2.02019-07-07T19:00:59Zbastlproblems with semaphores in ghc-6.10.4 unix-2.3.2.0```
module Main ( main ) where
import System ( getArgs )
import Control.Monad
import Data.List
import System.Posix.Semaphore
import System.Posix.Files
main = do
c <- liftM (head . head) getArgs
putStrLn $ "Writing " ++ [c] ++ " to ...```
module Main ( main ) where
import System ( getArgs )
import Control.Monad
import Data.List
import System.Posix.Semaphore
import System.Posix.Files
main = do
c <- liftM (head . head) getArgs
putStrLn $ "Writing " ++ [c] ++ " to file foo"
s <- semOpen "fooSemaphor" (OpenSemFlags True False) ownerModes 1
semWait s
appendFile "foo" $ replicate 99999999 c
semPost s
semUnlink "fooSemaphor"
putStrLn $ "Done writing " ++ [c]
```
When called like this "./locking2 a & ./locking2 b" I get:
```
locking2: fooSemaphor: semUnlink: does not exist (No such file or directory)
locking2: error: a C finalizer called back into Haskell.
This was previously allowed, but is disallowed in GHC 6.10.2 and later.
To create finalizers that may call back into Haskll, use
Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr.
```
I dont know what this means, but it looks as if some things are going wrong internally.https://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>https://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/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/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/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/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/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/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/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/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":[]} -->dtereidterei