On 01/15/2014 11:33 AM, Baruch Siach wrote: > Hi Mike, > > On Tue, Jan 14, 2014 at 05:45:51PM -0500, Mike Frysinger wrote: >> On Tuesday 14 January 2014 13:53:02 Baruch Siach wrote: >>> On Tue, Jan 14, 2014 at 05:46:50PM +0000, Pádraig Brady wrote: >>>> I noticed this issue from: >>>> http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/73294 >>>> >>>> I've not tested the following on uclibc, but does the attached patch fix >>>> it? (you just need to patch the m4/spawn_h.m4 file in coreutils to test >>>> this) >>> >>> I guess it should fix the problem, but it would be better to fix uClibc. >> >> unless POSIX explicitly states that the symbols be in -lc, i don't think >> uClibc is broken. i don't believe POSIX states that (if it does, please >> point >> out in the docs). >> >> keeping them in -lrt over -lc makes a bit of sense in my mind: >> - the POSIX docs label them as "ADVANCED REALTIME" (ok, ok, maybe i'm >> reaching here as what POSIX calls "realtime" is often not really "realtime" >> related) >> - these funcs are not common (that i've seen). that means always >> mapping >> them in via libc.so is useless overhead. better to penalize the uncommon.
That does make sense from uclibc's point of view. Note coreutils doesn't actually need these as I think it was an errant dependency spec that pulled them in. I've sent a patch to coreutils which will be in the next release if correct. > So this is a NACK for my patch moving posix_spawn to -lc. I'll copy this in > reply to the patch on the uclibc list. > Pádraig, your patch fixes the build problem of coreutils by correctly > detecting the -lrt dependency of posix_spawn. Thanks for confirming. Pádraig.
