On Thu, Jul 17, 2014 at 08:24:07AM -0500, Rob Landley wrote: > > On 07/17/14 08:12, Rob Landley wrote:> On 07/17/14 00:58, technosaurus wrote: > >> I think this is the same as daemonize() in toybox/lib. Should daemonize > >> just be defined to daemon(0,0) or is there a reason for it? > > > > daemon() isn't posix, so I have to figure out if it's best to > > reimplement it for portability, or just stick with the libc function we > > inherited from BSD and wait for the standard to catch up. In the > > meantime, it's in lib/pending.c for the same reason toys/pending exists, > > as toys/pending/README says this stuff needs further review. > > daemon() was removed for SUSv2; glibc makes it available if _XOPEN_SOURCE < 500 or if _BSD_SOURCE is defined (which includes the default).
Recent OS X versions (>10.5) mark daemon() as deprecated, and use of it there may cause an FTBFS. Everywhere else (at least on Linux and *BSD), daemon() is supported and widely used. glibc, musl, klibc, bionic, presumably olibc: standard; uclibc, newlib?: optional; dietlibc: in -lcompat So if we're still targetting "Linux, and maybe eventually BSD," use daemon(). If we might care about OS X or Darwin (the open source portion of OS X), maybe put daemonize() in lib/portability.c and probe for daemon(); if building a test program fails, use the daemonize() code, but otherwise just call daemon() (or define daemonize to daemon...). Note: if OS X errors on deprecated functions, using a local daemon() function also might not work, since there is still the daemon() function in libc... Thanks, Isaac Dunham _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
