GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-02-07T17:15:08Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/22454macOS: semaphore related deprecation warnings when building compiler2023-02-07T17:15:08ZAlex DmacOS: semaphore related deprecation warnings when building compilerWhile building ghc stage 1, I noticed these warnings:
```
/var/folders/fw/n1sdyp616tz20jfs2h0qzngr0000gq/T/ghc57747_0/ghc_2.c:9:106: error:
warning: 'sem_getvalue' is deprecated [-Wdeprecated-declarations]
|
9 | HsInt ghczuwrapper...While building ghc stage 1, I noticed these warnings:
```
/var/folders/fw/n1sdyp616tz20jfs2h0qzngr0000gq/T/ghc57747_0/ghc_2.c:9:106: error:
warning: 'sem_getvalue' is deprecated [-Wdeprecated-declarations]
|
9 | HsInt ghczuwrapperZC0ZCunixzm2zi7zi3ZCSystemziPosixziSemaphoreZCsemzugetvalue(void* a1, int* a2) {return sem_getvalue(a1, a2);}
| ^
HsInt ghczuwrapperZC0ZCunixzm2zi7zi3ZCSystemziPosixziSemaphoreZCsemzugetvalue(void* a1, int* a2) {return sem_getvalue(a1, a2);}
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/semaphore.h:54:56: error:
note: 'sem_getvalue' has been explicitly marked deprecated here
|
54 | int sem_getvalue(sem_t * __restrict, int * __restrict) __deprecated;
| ^
int sem_getvalue(sem_t * __restrict, int * __restrict) __deprecated;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:196:40: error:
note: expanded from macro '__deprecated'
|
196 | #define __deprecated __attribute__((__deprecated__))
| ^
#define __deprecated __attribute__((__deprecated__))
^
1 warning generated.
/var/folders/fw/n1sdyp616tz20jfs2h0qzngr0000gq/T/ghc57747_0/ghc_8.c:9:106: error:
warning: 'sem_getvalue' is deprecated [-Wdeprecated-declarations]
|
9 | HsInt ghczuwrapperZC0ZCunixzm2zi7zi3ZCSystemziPosixziSemaphoreZCsemzugetvalue(void* a1, int* a2) {return sem_getvalue(a1, a2);}
| ^
HsInt ghczuwrapperZC0ZCunixzm2zi7zi3ZCSystemziPosixziSemaphoreZCsemzugetvalue(void* a1, int* a2) {return sem_getvalue(a1, a2);}
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/semaphore.h:54:56: error:
note: 'sem_getvalue' has been explicitly marked deprecated here
|
54 | int sem_getvalue(sem_t * __restrict, int * __restrict) __deprecated;
| ^
int sem_getvalue(sem_t * __restrict, int * __restrict) __deprecated;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:196:40: error:
note: expanded from macro '__deprecated'
|
196 | #define __deprecated __attribute__((__deprecated__))
| ^
#define __deprecated __attribute__((__deprecated__))
^
1 warning generated.
```
macOS 12.5.1 (aarch64)https://gitlab.haskell.org/ghc/ghc/-/issues/19525getGroupEntryForName gives different result on WSL22021-04-06T14:45:03ZSimon Peyton JonesgetGroupEntryForName gives different result on WSL2I’ve just installed WSL2 and built GHC.
I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can’t push a change to master because that’ll affect everyon...I’ve just installed WSL2 and built GHC.
I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can’t push a change to master because that’ll affect everyone else.
Any ideas?
```
=====> 1 of 1 [0, 0, 0]
]0;getGroupEntryForName(normal) 1 of 1 [0, 0, 0]Actual stderr output differs from expected:
--- getGroupEntryForName.run/getGroupEntryForName.stderr.normalised 2021-03-09 22:36:01.300421100 +0000
+++ getGroupEntryForName.run/getGroupEntryForName.run.stderr.normalised 2021-03-09 22:36:01.300421100 +0000
@@ -1 +1 @@
-getGroupEntryForName: getGroupEntryForName: does not exist (no such group)
+getGroupEntryForName: getGroupEntryForName: does not exist (No such process)
*** unexpected failure for getGroupEntryForName(normal)
```
For info, about my system:
```
bash$ uname -a
Linux MSRC-3645512 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
bash$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
```https://gitlab.haskell.org/ghc/ghc/-/issues/1487unix package: test needed for getLoginName2019-07-07T19:13:17ZSimon Marlowunix package: test needed for getLoginNameI disabled the test for `getLoginName` in unix/tests/user001 because `getLoginName` cannot be called unless stdin is a terminal, which it isn't during an unattended build. Perhaps we can test this by setting up a pseudoterminal first, bu...I disabled the test for `getLoginName` in unix/tests/user001 because `getLoginName` cannot be called unless stdin is a terminal, which it isn't during an unattended build. Perhaps we can test this by setting up a pseudoterminal first, but that requires the pty patches which aren't in yet.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"unix package: test needed for getLoginName","status":"New","operating_system":"Unknown","component":"libraries/unix","related":[],"milestone":"6.8 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I disabled the test for `getLoginName` in unix/tests/user001 because `getLoginName` cannot be called unless stdin is a terminal, which it isn't during an unattended build. Perhaps we can test this by setting up a pseudoterminal first, but that requires the pty patches which aren't in yet.","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://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/8293user001 spuriously fails if getGroupEntryForID correctly fails2019-07-07T18:45:41ZEdward Z. Yanguser001 spuriously fails if getGroupEntryForID correctly failsIn some cases, a user's current group ID can be a number for a non-existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc...In some cases, a user's current group ID can be a number for a non-existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc/groups is not to be considered reliable. Unfortunately, the user001 has no way of telling that the failure is proper, and fails the test anyway. We ought to do something more robust.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"user001 spuriously fails if getGroupEntryForID correctly fails","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":"In some cases, a user's current group ID can be a number for a non-existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc/groups is not to be considered reliable. Unfortunately, the user001 has no way of telling that the failure is proper, and fails the test anyway. We ought to do something more robust.","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/8713Avoid libraries if unneeded (librt, libdl, libpthread)2019-07-07T18:43:49Zip1981Avoid libraries if unneeded (librt, libdl, libpthread)I have GHC on an unusual system \[1\]
libdl.so.1, librt.so.1 and some others are "filter libraries": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linki...I have GHC on an unusual system \[1\]
libdl.so.1, librt.so.1 and some others are "filter libraries": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-)
Unfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this:
```
# ghci -package unix
GHCi, version 7.6.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 array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package unix-2.7.0.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type)
```
The unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains.
I use the attached patch for GHC 7.6.3 to fix this issue.
In general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB
\[1\] http://osdyson.org
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | GhcDoesn'tWork |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"libdl, libpthread may be unwanted too","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have GHC on an unusual system [1]\r\n\r\nlibdl.so.1, librt.so.1 and some others are \"filter libraries\": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-)\r\n\r\nUnfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this:\r\n\r\n{{{\r\n# ghci -package unix\r\nGHCi, version 7.6.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 array-0.4.0.1 ... linking ... done.\r\nLoading package deepseq-1.3.0.1 ... linking ... done.\r\nLoading package bytestring-0.10.0.2 ... linking ... done.\r\nLoading package old-locale-1.0.0.5 ... linking ... done.\r\nLoading package time-1.4.0.1 ... linking ... done.\r\nLoading package unix-2.7.0.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type)\r\n\r\n}}}\r\n\r\nThe unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains.\r\n\r\nI use the attached patch for GHC 7.6.3 to fix this issue.\r\n\r\nIn general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB\r\n\r\n[1] http://osdyson.org","type_of_failure":"GhcDoesn'tWork","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16099expose st_blksize field from fstat syscall2019-07-07T18:01:31ZPhilippeexpose st_blksize field from fstat syscallThe libc manual talks about buffer sizes.
https://www.gnu.org/software/libc/manual/html_node/Controlling-Buffering.html
They advise:
Actually, you can get an even better value to use for the buffer size by means of the fstat system cal...The libc manual talks about buffer sizes.
https://www.gnu.org/software/libc/manual/html_node/Controlling-Buffering.html
They advise:
Actually, you can get an even better value to use for the buffer size by means of the fstat system call: it is found in the st_blksize field of the file attributes. See Attribute Meanings.
It's just that the st_blksize field it stepped over in the haskell definition of it:
https://github.com/haskell/unix/blob/8d188ed8067af17dfcc2cd6cbbfda7294ba17e17/System/Posix/Files/Common.hsc\#L280-L283
Which goes directly from filesize to accesstime
See also https://linux.die.net/man/2/fstat
Would be nice to expose the additional fields as well
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"expose st_blksize field from fstat syscall","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The libc manual talks about buffer sizes.\r\n\r\nhttps://www.gnu.org/software/libc/manual/html_node/Controlling-Buffering.html\r\n\r\nThey advise:\r\nActually, you can get an even better value to use for the buffer size by means of the fstat system call: it is found in the st_blksize field of the file attributes. See Attribute Meanings.\r\n\r\nIt's just that the st_blksize field it stepped over in the haskell definition of it:\r\n\r\nhttps://github.com/haskell/unix/blob/8d188ed8067af17dfcc2cd6cbbfda7294ba17e17/System/Posix/Files/Common.hsc#L280-L283\r\n\r\nWhich goes directly from filesize to accesstime\r\n\r\nSee also https://linux.die.net/man/2/fstat\r\n\r\nWould be nice to expose the additional fields as well","type_of_failure":"OtherFailure","blocking":[]} -->