On Sat, 2012-09-22 at 17:20 +0100, peter green wrote: > Russell Coker wrote: > > On Sun, 23 Sep 2012, peter green <plugwash@p10link.net> wrote: > > > >> In order to build successfully nacl needs to determine the CPU frequency > >> (the CPU frequency determined at build time is not used in the final > >> binaries afaict but if it's not determined then the build will fail as > >> it will consider the implementation broken and if it can't find any > >> non-broken implementations it won't build). > >> > > > > If the build process is trying to discover information that it then discards > > then why not just patch it to not do so? > It's not the build process itself doing the determination, it's the code > being built and > tested (as I said the build process tries various implementations until > it finds one that > works), [...] So the build process is trying to determine which method will work? Then what if it settles on some method that is available on the build machine's kernel, but not the target distribution's kernel? I think you need to either (1) make it defer this to run-time or (2) force the decision at build-time, and be conservative. (In general, userland packages in testing/unstable should not depend on kernel features that aren't in the official kernel packages in stable, as this can cause breakage during upgrades.) Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one.
Attachment:
signature.asc
Description: This is a digitally signed message part