[MacPorts] #36984: fetchmail - BUG in libdispatch client - ML 10.8.2

[MacPorts]

#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