Hi Richard, It is not my primary objective to make your project run under uclibc. I'm working on a project that uses Linuxptp on an embedded system, so I needed to integrate it into Buildroot. Since it was failing the integration test, I had to patch it. And I contributed my patches because I find it good that the community can profit from it.
I can't find any rational argument against test-compiling a piece of code in that negatively loaded emotional outburst you referred to. So I still don't see anything conceptually wrong on my patch. If you don't like it, please take my email just as a bugreport: linuxptp fails to build with uclibc, details in my previous emails. I don't have the time and resources to investigate this deeper. Regards Petr On 22/05/17 06:51, Richard Cochran wrote: > On Mon, May 22, 2017 at 12:09:06AM +0200, Petr Kulhavy wrote: >> I'm not a uclibc expert, so I can't answer under what conditions >> clock_nanosleep is defined. TYou would need to ask the uclibc authors. > And just who might they be? > > If you want this to work on uClibc, then *you* could ask them! > >> But I don't see any configuration options for uclibc in Buildroot, > But what about in uClibs itself? > >> the >> existence of clock_nanosleep seems to be rather uclibc version and platform >> dependent. > That sounds like a promising lead... > >> # ifdef __USE_POSIX199309 >> >> or >> >> # if defined __USE_XOPEN2K && defined __UCLIBC_HAS_ADVANCED_REALTIME__ >> # ifdef __UCLIBC_HAS_THREADS_NATIVE__ > If you find the right combination of feature test macros, then this > would be acceptable for our missing.h. > >> I neither understand or share your aversion to the autoconf approach. It is >> a standard and well working solution. In my view it is the best possible >> approach when running on a potentially unknown system. > That is your view. Mine is more like this: > > https://varnish-cache.org/docs/4.0/phk/autocrap.html > >> I've just brought my two cents in the form of a pragmatic and working >> proposal. If you have a better idea, feel free to implement it. Currently >> linuxptp seems to rather fail with uclibc. > And it is going to stay that way unless you can find a reasonable > solution that does not involve autotools or compiling test programs. > > Sorry, > 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
