Hi Michael,
On 2011/04/07 2:47, Michael Stahl wrote:
make -r deliverlog running on OpenSolaris x86 prints same type of warning
messages and then eventually create the log file.
$ make -r deliverlog
...
make: *** Warning: .LOW_RESOLUTION_TIME file
`/xxxxx/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time
stamp
...(repeated 2 by 500 times for each file)...
yes, this warning is a well-known problem.
On OpenSolaris x86, even after executing "make -sr&& make -r deliverlog," the
"delivered" file under $OUTDIR is slightly older (in nanoseconds) than its original one.
Consequently, copy action might occur again and again. Should I use /usr/gnu/bin/cp instead of /bin/cp, or
else???
btw, in DEV300m106 configure will now find /usr/gnu/bin/cp on Solaris, and
use it :)
Good!
$ stat $OUTDIR/inc/svx/sxsoitm.hxx
...
Modify: 2011-02-22 20:59:42.717474000 +0900
...
$ stat svx/inc/svx/sxsoitm.hxx
...
Modify: 2011-02-22 20:59:42.717474450 +0900
...
that is exactly the problem that is solved by using the
.LOW_RESOLUTION_TIME directive in the rules in Deliver.mk.
ZFS has nano-second precision timestamps.
as mentioned above, when copying files to the solver, gbuild preserves the
timestamp of the source files, to prevent rebuilds in dependent modules.
this is done using --preserve=timestamp option of GNU cp if it is
available, and touch -r otherwise (such as in your case probably).
unfortunately older versions of GNU cp, as well as Solaris 10 touch, only
support micro-second precision timestamps.
the result is that on every make invocation the files will be copied
again, which is bad.
to work around this, GNU make provides the .LOW_RESOLUTION_TIME option,
which does not check the sub-second part of the timestamp.
however, because the timestamps do have a sub-second part that is not
zero, GNU make produces this annoying warning, and unfortunately there
seems to be no way to turn it off.
i haven't checked yet, but if the GNU cp in OpenSolaris can actually copy
nano-second timestamps properly, then you can set the gb_HIRESTIME
variable, so the .LOW_RESOLUTION_TIME is not used and the warnings go away.
I've just tried it and learned that unfortunately, version 6.7 of "/usr/gnu/bin/cp
-p" truncates nanosecond part during copying a file.
you can set the GNUCOPY variable, or rebase to m106 where configure should
find it automatically.
Surfing in the Internet, I have devised a silly, pragmatic workaround.
1. Truncate sub-second part of all files in the module svx:
$ find svx -type f | xargs perl -e 'map{ $t=(stat($_))[9]; utime($t,$t,$_) }
@ARGV'
$ stat svx/inc/svx/sxsoitm.hxx
...
Access: 2011-02-22 20:59:42.000000000 +0900
Modify: 2011-02-22 20:59:42.000000000 +0900
Change: 2011-04-07 03:58:23.672122611 +0900
2. Do the same thing on the target files, just one time:
$ find $OUTDIR/inc/svx -type f | xargs perl -e 'map{ $t=(stat($_))[9];
utime($t,$t,$_) } @ARGV'
3. Give it a try:
$ make -sr deliverlog
[ build LOG ] svx
Yahhoooo, "make" abandons complaining about .LOW_RESOLUTION_TIME.
That is, I know, just for fun. :-)
Best regards,
Tora
--
-----------------------------------------------------------------
To unsubscribe send email to [email protected]
For additional commands send email to [email protected]
with Subject: help
