Hi Richard, I'm not sure that you fully understand the problem. It seems there are currently four scenarios possible. 1) Some earlier versions of uclibc don't have clock_nanosleep() at all. In some versions it is configurable as you correctly mentioned, so we have case 2) is present and selected, 3) is present and not selected. 4) On some architectures it might not be present at all even with the newer version of the library. Quoting the uclibc documentation of the HAS_ADVANCED_REALTIME option: "These functions are part of the Timers option and need not be available on all implementations."
That is the current situation. In software engineering you rely on well defined APIs or standards like POSIX or C11. Not on internals or particular implementation of other libraries - that would be a bad programming practice. The __UCLIBC_HAS_ADVANCED_REALTIME__ is part of uclibc internals and does not even guarantee the presence of clock_nanosleep(). Now the question is how to handle this less than optimal situation of uclibc. One option is to clearly define the boundaries where your software runs, i.e. put the required libraries or features into prerequisites. The other option (which linuxptp follows) is to detect the features and adapt or workaround the missing features (missing.h). Modifying the uclibc doesn't solve the problem for the past uclibc versions until now. Unless you want to be compatible only from some future version of uclibc on, it is not an option. Relying on internals of uclibc is not reliable (see the above quote), not clean and will work only until someone from uclibc decides to change the name of the config option. 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. 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. Regards Petr On 23/05/17 07:07, Richard Cochran wrote: > On Mon, May 22, 2017 at 11:05:39PM +0200, Petr Kulhavy wrote: >> I can't find any rational argument against test-compiling a piece of code in >> that negatively loaded emotional outburst you referred to. > you still have to do the hard work and figure out the right way to > explain to the autocrap tools what you are trying to do and how to do > it > > Compiling a test program is a lazy work around that fails to address > real issues. In this case, the problem is that sometimes uClibc omits > clock_nanosleep. > > 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. > >> I don't have the time and resources to investigate this deeper. > Right, and that is the point. It is "hard work" to find a proper > solution. Blindly slapping on autotools or similar is a cop-out. > > 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
