#36984: fetchmail - BUG in libdispatch client - ML 10.8.2 ------------------------+------------------- Reporter: srothe@… | Owner: pmq@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: Port: fetchmail | ------------------------+------------------- Comment (by matthias.andree@…): Greetings, I am the current upstream maintainer of fetchmail, am unaware of MacOS X idiosyncrasies beyond the mere fact that it exists, and causes irritation with GCD idiosyncrasies and recent MacOS X regressions. Having said that, I also know nothing of otool or .dylibs or any of that stuff, and I do not care to learn any of that stuff, or obtain MacOS X. I have not got the faintest clue as to why a single-threaded application needs to deal with threading garbage. Very irritating. Documentation on this GCD requirement (keep file descriptor open, how to avoid GCD altogether, ...) is scarce and/or hard to find. I looked around Apple's developer docs, googled for quite a while without coming up with anything substantial, except that a few ported applications are also trapped by these GCD file descriptor idiosyncrasies, and apparently GCD has recently gotten in the fad of killing applications rather than just complaining. I find it strange that a UNIX-derived system is now breaking a UNIX application that has been around for far more of a decade -- and I am a bit alienated by the whole story: 1. apparently the whole issue only appears if NLS (through gettext/libintl) is in use. LC_ALL=C appears to avoid it, according to srothe@'s reports. 2. apparently the operating system forces underdocumented premature threading stuff on my single-threaded application 3. apparently the operating system also imposes open file descriptors on my single-threaded application. 4. Documentation on this GCD requirement (keep file descriptor open, how to avoid GCD altogether, ...) is scarce and/or hard to find. What I need is: 1. I need to be able to close all file descriptors in the daemonize() functionm before and/or after close()ing all open file descriptors. That is how Unix has worked for ages, this is required to let go of controlling terminals and thereabouts so we can thoroughly detach from the process that launched fetchmail in order to go in the background. 2. How do I avoid the system forcing additional constraints on my application that are in direct violation of relevant standards (details below)? 3. How do I determine when this descriptor needs to remain open, and which one it is? I am not ready to break my application for other Unices just because one OS acts up and imposes restrictions that violate the Single Unix Specification aka. IEEE Std 1003.1; If MacOS X believes I must not close its special file descriptor, it is required, that it - when I call close(SPECIAL_MACOS_FILE_DESC) - sets errno = EBADF and returns -1, rather than kill the application. Now, how can we resolve the mess without depriving end users of established fetchmail functionality (such as NLS or background/daemon mode) that they could successfully use in earlier MacOS X 10.n versions? -- Ticket URL: <https://trac.macports.org/ticket/36984#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS