Sorry for letting this slip off my radar for the best part of a year
after uploading the "diagnostic upload". Here is a list of facts i've
determined.
1: NACL contains some code for measuring times in CPU cycles, it is not
clear to me how important a part of the whole package this is.
2: There are various CPU specific implementations of this code which
work using various performance counters.
3: There are also generic implementations which work by measuring time
in some unit other than CPU cycles and then measuring
4: The generic implementations need to have a CPU speed CPU speed, they
determine this by looking at various files in /sys and /proc . Some
kernel/hardware combinations have the CPU speed available in a place
where NACL looks, others don't. My investigations didn't reveal any
generic way of measuring CPU clockspeed on linux.
5: The build system chooses what implementation to use not by knowlage
of what each debian port is supposed to support but by bruteforcing
until one is found to build and work.
6: Some of the generic implementations fail to build not because they
are incompatible with the system they are being built on but because
they aren't being linked correctly by the build system.
7: mips is still failling to build with a timeout
Now for some implications of these facts.
Point 4 is the issue with the armel and armhf. I'm not sure of any good
fixes for this one. The only thing I can propose is using bogomips as a
psuedo CPU speed if the true CPU speed can't be read but I don't know
how acceptable that would be for this package. IME on boards where none
of the CPU speed determining methods used by the program currently work
bogomips is very close to CPU clock. If you belive this is a sane way to
go i'm happy to whip up a patch implementing it.
Point 5 means that builds are unpredictable and the implementation
chosen may depend on which buildd happens to build the package and may
not work for all users. It seems wrong in much the same way that using
-march=native is wrong.
Point 6 means that on systems where we need to use the generic
implementation we would end up with an inferior implementation using the
non-monotonic clock.
Point 7 needs more investigation if people want the package on mips but
i'm an arm guy not a mips guy.
In summary it's a horrible mess.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
