clock skew detected in archive member

clock skew detected in archive member

[Schwarz, Konrad]

Hello,

I am building a project in Cygwin using a GCC/binutils cross-compiler hosted on Windows.
I.e., make and other utilities are from Cygwin;
gcc, ld, ar, etc. are from the cross-compiler toolchain which was compiled natively
for Windows.

I consistently see
	make[1]: Warning: File 'libmylib.a(myfile.o)' has modification time 3516 s in the future
	make[1]: warning:  Clock skew detected.  Your build may be incomplete.

(The exact time varies somewhat).

The build is indeed incomplete.

I am using the lib(member): form of rule in the Makefile, so
make uses the modification time of the member in the archive
to see if it needs updating.

As the time is close to an hour and since I am one hour east of GMT,
this might be related to a time-zone problem.

If anyone has run across this problem and has some hints for me,
I would be most grateful.

Best Regards

Konrad Schwarz

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: clock skew detected in archive member

[Brian Inglis]

Schwarz, Konrad <konrad.schwarz <at> siemens.com> writes:
> I am building a project in Cygwin using a GCC/binutils cross-compiler
hosted on Windows.
> i.e., make and other utilities are from Cygwin;
> gcc, ld, ar, etc. are from the cross-compiler toolchain which was compiled
natively for Windows.
> I consistently see
> 	make[1]: Warning: File 'libmylib.a(myfile.o)' has modification time 3516
s in the future
> 	make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> (The exact time varies somewhat).
> The build is indeed incomplete.
> I am using the lib(member): form of rule in the Makefile, so make uses the
modification time of the member in the archive to see if it needs updating.
> As the time is close to an hour and since I am one hour east of GMT, this
might be related to a time-zone problem.
> If anyone has run across this problem and has some hints for me, I would
be most grateful.

Are you storing any of your build input or output on a network drive? 
There can be problems with server<->Windows<->Cygwin conversions of file
times from some network servers. 
Do builds with all files on a local drive for time stamp consistency. 

Are timezone updates and settings for your Windows and Cygwin environments
current and identical e.g. Europe/Berlin or equivalent? 

make -d will show you what files and times are being compared. 
Run ls -l and cmd dir, and Windows and Cygwin ar -tv on the inputs and
outputs to see what both sides see for file and member timestamps. 
 
make -B will force a complete rebuild as a workaround. 

You may have to find a Windows build of make that handles archive member
file times consistently with your Windows cross-ar, and perhaps also a shell
for use by make, if build scripts do any explicit time operations. 



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: clock skew detected in archive member

[Frank Farance]

On 2016-07-19 15:44, Schwarz, Konrad wrote:
> Hello,
>
> I am building a project in Cygwin using a GCC/binutils cross-compiler hosted on Windows.
> I.e., make and other utilities are from Cygwin;
> gcc, ld, ar, etc. are from the cross-compiler toolchain which was compiled natively
> for Windows.
>
> I consistently see
> 	make[1]: Warning: File 'libmylib.a(myfile.o)' has modification time 3516 s in the future
> 	make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>
> (The exact time varies somewhat).
>
> The build is indeed incomplete.
>
> I am using the lib(member): form of rule in the Makefile, so
> make uses the modification time of the member in the archive
> to see if it needs updating.
>
> As the time is close to an hour and since I am one hour east of GMT,
> this might be related to a time-zone problem.
>
> If anyone has run across this problem and has some hints for me,
> I would be most grateful.
>
> Best Regards
>
> Konrad Schwarz

Konrad-

Here is my experience operating in a mixed environment.  There seem to be 
several routes to getting timestamps on files ... Windows (via Windows explorer) 
can produce different results than Cygwin, even on the same NTFS volume.  Now if 
you were able to roll the clock back a couple months to Winter time, you might 
have fewer problems.  Not to mention, if you're using remotely mounted drives, 
there can be some jitter too that causes Makefile problems -- these problems 
have been around for almost three decades on pure *nix systems, no Windows OS.

Now add in archives (whose time should be right because it is in UTC), but the 
file itself (which was copied into the archive) might have the wrong time 
(stupid TZ issues from the file's metadata in the filesystem, not the archive 
which merely copies the filesystem metadata).

The easiest way to see this problem is with files that are "self-timestamped", 
such as JPEG EXIF metadata in a photo file taken in December (Northern 
Hemisphere winter) and viewed in Summer time (or vice versa).  You'll see hour 
differences, which of course are not true.

The solution?  Essentially, (1) you need to build on local filesystems (applies 
to UNIX and Windows OS), (2) you need to have a single route for determining 
timestamp/TZ data on files (probably means you can't mix Windows and Cygwin), 
(3) building the files with "TZ=UTC0" (or equivalent) should minimize timezone 
and summer time issues.

I'm sure there is a more detailed explanation in the inner guts of cygwin and 
Windows OS, but I've lost too much time over the years trying to make sense out 
of it and reconciling what has been written on the web that, in fact, does not 
describe what is happening on my machines.  The timezones/summer time has been 
broken on DOS and Windows since Day 1, and they broke it again, and they broke 
it again.

-FF

-- 
______________________________________________________________________
Frank Farance, Farance Inc.    T: +1 212 486 4700   M: +1 917 751 2900
mailto:frank@farance.com       http://farance.com
Standards/Products/Services for Information/Communication Technologies

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple