On Tue, May 23, 2017 at 11:43:57AM +0200, Petr Kulhavy wrote: > I'm not sure that you fully understand the problem. It seems there are > currently four scenarios possible.
Yeah, I get that. Your task then would have been to address the four possibilities. > Now the question is how to handle this less than optimal situation of > uclibc. Right, and I explained how to do that: > >The real solution is to figure out why, and fix that in uClibc. A > >second, less optimal solution would be to figure out how uClibc's > >feature test macros advertise presence of clock_nanosleep (if indeed > >they do that) and use those macros in missing.h. > Since the library doesn't provide a clear API or indication whether the > required feature is present and since this is C and not Java, there is no > clean way how to detect it. On the contrary, there is a clean way. One can use the feature test macros. Patch follows. > That said, the test compilation is still the best working, forward > compatible, portable and clean approach (the only well defined API is the > header) for the current situation. Repeating this assertion over and over again doesn't make it any more true. You did come close to finding the simple solution to building against uClibc, but instead of taking that last step, you slapped on an autoconf-like workaround. The whole point of phk's "rant" article is that we really should strive for proper solutions when it comes to portability. Many times, this requires the hard work of analyzing the problem in order to find the best solution. Thanks, Richard ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
