Re: Clock skew detected warning
Any intelligent operating system will store timestamps in a canonical format that does not jump around wildly when changing timezones or entering/exiting daylight savings. Yes, and Windows does this. I don't use Windows so I don't know how it works: maybe it does the intelligent thing, too, and there's something else wrong here. Yes. One common reason is that a system adminstrator has chosen to override the default clock synchronization mechanism (which, these days, is a passable implementation of ntp) and to synchronize the clock to local time, rather than to the One True UTC by some other method. My first port of call would be to find out the time zone configuration of the machine in question and how its clock is being synchronized. -- Martin's BlackBerry, BlueArc Engineering -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: Li, Shiping (Sam) [EMAIL PROTECTED] CC: bug-make@gnu.org bug-make@gnu.org Sent: Sun Apr 02 22:22:06 2006 Subject: Re: Clock skew detected warning %% Li, Shiping \(Sam\) [EMAIL PROTECTED] writes: ls I am using gnumake to build a code and got below errors: ls gnumake[2]: warning: Clock skew detected. Your build may be ls incomplete. ls . ls gnumake.exe[1]: *** Warning: File `../../videoss/mp4/dec/src/mp4d_mb.d' ls has modification time in the ls future (2006-04-02 22:48:35 2006-04-02 21:49:07) ls ls I think normally people met this problem in NFS server because of ls the clock sync problem, but they are talking about 2 seconds at ls most. In my case, it is one hour! ls I think it may caused by summer time, it started today (April 2nd) ls and it is the first day of summer time. I met this problems in ls two PCs. I am using winXP and all the files are stored locally. Well, if this is true then Windows has a stupid implementation of timestamps. Any intelligent operating system will store timestamps in a canonical format that does not jump around wildly when changing timezones or entering/exiting daylight savings. I don't use Windows so I don't know how it works: maybe it does the intelligent thing, too, and there's something else wrong here. You might consider asking on the make-w32@gnu.org mailing list to see if they have any advice there... this is a Windows-specific issue and they know much more about Windows than the folks reading this list. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #9062] Need access to pathname of Makefile
Follow-up Comment #11, bug #9062 (project make): A reminder: this bug is a request for a variable whose value is the full path of the directory containing the Makefile, regardless of what the current directory is or how it got that way with -C, etc. There has been much discussion of the current directory, which is not relevant. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=9062 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.81 test failure
Paul, [EMAIL PROTECTED] (Paul Jarc) writes: + work/variables/INCLUDE_DIRS.mk:3: .INCLUDE_DIRS is empty This is probably because you built make with install prefix (--prefix) being a non-existent directory. Can you reconfigure make with something like --prefix /usr/local and see if this test still fails? -boris ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #16255] export a unique slot number
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16255 Summary: export a unique slot number Project: make Submitted by: egmont Submitted on: Monday 04/03/06 at 09:51 Severity: 3 - Normal Item Group: Enhancement Status: None Privacy: Public Assigned to: None Open/Closed: Open Component Version: 3.81 Operating System: Any Fixed Release: None ___ Details: It would be cool if at parallel builds make exported a shell variable whose value is a reasonably small integer that is unique amongst the jobs running at the same time. For example if I type make -j10 then this would be a number from the 0..9 interval. Rationale: we have a distributed build system where we build packages of a complete Linux distribution. The actual build is performed on several hosts, each one runs 1 build at a time. The main server controls the whole procedure using a Makefile set up based on the packages' build-time dependencies (loops eliminated), and performing a make -j number_of_build_hosts command to rebuild all the packages. Currently we have some dirty tricks to find a free client that does not run any build so is willing to accept the new one. I think it wouldn't be too hard for make to tell this explicitely, through the SLOT_NUMBER (or something else) environment variable. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=16255 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #14684] make fails if LC_CTYPE is iso_8859_1
Follow-up Comment #8, bug #14684 (project make):
On Solaris 10, with LC_CTYPE set to iso_8859_1, isblank returns zero for
isblank('\t'), which (at least for me) causes the problem described in the
original report.
The following program demonstrates the issue:
#include stdio.h
#include ctype.h
#include locale.h
int main(int argc,char** argv) {
setlocale(LC_ALL,);
printf(isblank=%d\n, isblank('\t'));
}
This behavior seems to be consistent, and it seems to be a bug in Solaris
rather than in make. I wonder, though, if make should maybe check for a
working isblank in the configure script?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14684
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: Probable Spam: make 3.81 cannot build gcc 4.x.y
Date: Mon, 03 Apr 2006 14:25:12 +0400 From: =?KOI8-R?Q?=E4=C5=CA=D4=C5=D2_=E1=CC=C5=CB=D3=C1=CE=C4=D2_=F7=C1?= =?KOI8-R?Q?=CC=C5=D2=C9=C5=D7=C9=DE?= [EMAIL PROTECTED] After update GNU make from 3.80 up to 3.81 i cannot build gcc 4.0.2, 4.0.3 and 4.1.0 whith same error: rm -f ./libgcov.a ar rc ./libgcov.a libgcc/./_gcov.o libgcc/./_gcov_merge_add.o libgcc/./_gcov_me rge_single.o libgcc/./_gcov_merge_delta.o libgcc/./_gcov_fork.o libgcc/./_gcov_e xecl.o libgcc/./_gcov_execlp.o libgcc/./_gcov_execle.o libgcc/./_gcov_execv.o li bgcc/./_gcov_execvp.o libgcc/./_gcov_execve.o ranlib ./libgcov.a make[2]: Leaving directory `/export/home/devel/build/gcc-4.0.3/objdir/gcc' echo timestamp stmp-multilib make[1]: Leaving directory `/export/home/devel/build/gcc-4.0.3/objdir/gcc' /bin/bash: -c: line 5: syntax error: unexpected end of file make: *** [multilib.out] Error 2 + exit Please at least show the line about which Bash complains. It's hard to know what's wrong without seing that much, and downloading the humongous GCC distro just to find out what that lines says is not my idea of fun... TIA ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Probable Spam: make 3.81 cannot build gcc 4.x.y
%% Regarding Probable Spam: make 3.81 cannot build gcc 4.x.y; t After update GNU make from 3.80 up to 3.81 i cannot build gcc 4.0.2, t 4.0.3 and 4.1.0 whith same error: t rm -f ./libgcov.a t ar rc ./libgcov.a libgcc/./_gcov.o libgcc/./_gcov_merge_add.o libgcc/./_gcov_merge_single.o libgcc/./_gcov_merge_delta.o libgcc/./_gcov_fork.o libgcc/./_gcov_execl.o libgcc/./_gcov_execlp.o libgcc/./_gcov_execle.o libgcc/./_gcov_execv.o libgcc/./_gcov_execvp.o libgcc/./_gcov_execve.o t ranlib ./libgcov.a t make[2]: Leaving directory `/export/home/devel/build/gcc-4.0.3/objdir/gcc' t echo timestamp stmp-multilib t make[1]: Leaving directory `/export/home/devel/build/gcc-4.0.3/objdir/gcc' t /bin/bash: -c: line 5: syntax error: unexpected end of file t make: *** [multilib.out] Error 2 I pulled down the gcc-core tarball for 4.1.0 and couldn't reproduce this problem. In my build I see the libgcov.a library get built, but then noplace during the build does it ever do anything with a stmp-multilib file. That file must be part of one of the additional parts of GCC. I consider it very likely that this portion wasn't updated to reflect the changes in make 3.81, but the only way to know for sure is if someone can tell us in which part of GCC the multilib is built so we can look at it. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
