Harlan Stenn <st...@ntp.org> wrote: > "Jason Rabel" writes: >> > There are two obvious ways to go for an embedded client. >> > >> > One way would be to use the sntp code as the base. >> > >> > The other would be to either use the current NTP codebase and use the >> > configure options to disable all the refclocks and anything else you >> > didn't want, or wait until we're done with the post-4.2.8 rewrite. For >> > post-4.2.8, we're looking at having a "client core" with any refclock >> > code being handled a separate process. >> >> I do not know if this is the case with NTP, but quite often it takes >> considerable hacking of sources to get code to compile on non-x86 >> embedded hardware (i.e. ARM & MIPS)... It would probably help boost usage >> if someone was assuring NTP sources compile on those platforms without >> the need for modification. > > That hasn't been my experience. But if those platforms need switches > people just need to send in the patches so we can have configure.ac > handle them. I'm happy to help out.
I don't think it is true at all. I have compiled several existing programs on a Raspberry Pi and I have not encountered any particular problems that one would not see when compiling a program that has only ever been tried on 64-bit Intel on a 32-bit Intel system. As the ARM is usually little-endian, even endianness issues don't arise. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
