| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 9790.1 | Too fast considered harmful?! | TLE::EKLUND | Always smiling on the inside! | Tue May 13 1997 12:03 | 13 |
| You asserted that it "compiles code so fast that make doesn't
always work." Could you elaborate on why you think the speed of
compilation contributes to this problem? I don't have the
foggiest notion of how make deals with file dates (you have to
understand that I don't use make, since I like to take advantage
of all the benefits of compiling everything at once - inlining,
etc.). I'd like to know whether anyone thinks the compiler(s)
should do something about this (other than slow down!).
Cheers!
Dave Eklund
(who admits to helping to speed up the compiler...)
|
| 9790.2 | Unique timestamps? Or NFS problem?? | HELIX::SONTAKKE | | Tue May 13 1997 12:21 | 6 |
| I wonder if being the "fast compiler" implies identical time stamp on
the both source and obj file. I still don't know why and how that will
confuse make, but the recently discussed MICRO_TIME option would
eliminate that as a possibility.
- Vikas
|
| 9790.3 | Fast is GOOD! | DV780::ENGQUIST | Eric Engquist | Tue May 13 1997 16:46 | 12 |
| .1 - No, I think it is great, this problem was only every seen on a
Cray. Hence it does make us look real good.
Make looks a time stamps to determine if a piece of code
should be remade or not. In the ar statement the $? is
too do the archive on all the .o's that have changed. The
fix that Cray did was to make sure that the date was
checked to see if it was less than or equal.
.2 - We did turn on MICRO_TIME, to no avail. I need to check the
kernel to make sure it is really on.
|
| 9790.4 | | TLE::EKLUND | Always smiling on the inside! | Tue May 13 1997 17:47 | 5 |
| Are these nfs mounted disks?
Cheers!
Dave Eklund
|
| 9790.5 | | HELIX::SONTAKKE | | Wed May 14 1997 14:34 | 6 |
| How does make handle case where the source and the object reside on
different nfs server? OR rather how does NFS handle the timestamp? A
clock skew on server/client could cause quite a grief if you don't have
synchronized time.
- Vikas
|
| 9790.6 | | DECWET::MARTIN | | Wed May 14 1997 15:18 | 3 |
| The timestamp for an NFS-served file is set to the time the client thinks it is.
So if source and object are both being modified from the same machine, even if
they're NFS served from different machines, make will work correctly.
|
| 9790.7 | Not NFS'ed | DV780::ENGQUIST | Eric Engquist | Wed May 14 1997 23:57 | 13 |
| This is local code on the machine. It is not NFS mounted. I have
a segment of the code and it is strange how it behaves on the make. I
did turn on MICRO_TIME and off KDEBUG to see if that was the problem.
I have a tar of it, and played with it the other night. I would do a
make clean, then a make. Each time it would get an unresolved
due to one or more .o's not included in the archive. It seems to
be related to the ar $?. If I use ar $(OBJS) it works. $?
says to include only the .o's that were made. If you look at the
makefile output the .o is made. Each time you run it you get
a different error. I am going to try it on my DEC 3000 which is slower
and also on a 400MHz 500 I have to see what happens there. Both
of those are 4.0B. The machine having the issue is 433au running 4.0c
|
| 9790.8 | | NNTPD::"[email protected]" | Shashi Mangalat | Sat May 17 1997 00:38 | 13 |
| This may be an msync(2) problem. As I understand it, ld now uses mmap() and
msync() to write the object files. msync() has a known problem with not
updating file modification times. Although the interface is msync() the
time stamps are updated by the underlying file system. As far as I know both
UFS and AdvFS have problems with msync() and modification times. A problem
report was filed some time back regarding the msync() behaviour on AdvFS.
Sorry, I don't know the current status of it.
You might want to check the file modification time manually after an
object module is built to verify the above.
--shashi
[Posted by WWW Notes gateway]
|
| 9790.9 | | COL01::LINNARTZ | | Sun May 25 1997 07:39 | 19 |
| Eric, give the "/usr/opt/ultrix/usr/bin/make" a try. I had similar
problems with some objects not being fetched by using the standard
make.
I QAR'ed it first, but it end up in a discussion on how big the example
makefile should be which is fed into a QAR and that make will soon
change to standard POSIX and by this the problems should get solved.
As I had different priorities, I changed softlinks to and PATH var
that the "ultrix make is fetched first, which stopped at least customers
compalint's. Our make isn't to good (also has some problems with
white space) but after all the mail conversations with the engineer
I've put myself on the hopers waitlist to get fixed in next release.
By reading .-1 I'm not totally convinced that this is due to msync, as
this should happen with the ultrix make too. If you want to look at the
timestamps, use the make options "-npd" which outputs you the
timestamps (with a LOT" of other internal info)
Pit
|