Re: Hidden timeskew problems might show up on 2.6.x kernels
Jeroen van Wolffelaar <jeroen@wolffelaar.nl> writes:
> Hi,
>
> After quite a while being puzzled why my package, building fine on my
> computer, failed to be build by my sponsor. Everything indicated
> automake was being run, while it shouldn't.
>
> It turned out, that 2.6.x kernels support mtimes of high precision
> (nanoseconds rather than just seconds). Since in the diff file, the
> Makefile.in was patched before the Makefile.am, the .am got a newer
> mtime, and caused automake to be invoked. Swapping them around in the
> diff solved this. On my 2.4.x kernel, this didn't happen, because both
> were patched in the same second, but it always happened on my sponsor's
> machine...
The problem is well known and documented. A lot of packages got hit by
this when patch on the slower archs just happens to hit a second. The
longer patch takes the more likely a skew is, thats why its allways
the lowest systems finding it. With high precision mtimes that will
happen everywhere every time. Good.
Swapping them around in the diff is not realy an option. Next time you
build the package you probably forget to swap them around. Instead
touch the files in the right order in the rules file, as explained in
the docs.
> The issue here is, that it is very well possible that there are source
> packages in the archive, which were never build by 2.6.x kernels, and
> thus might very well contain the same miniscule timeskew problem.
M68k has allways been quite good at failing those.
MfG
Goswin
Reply to: