Discussion:
Problem with Build
(too old to reply)
Paul S. Person
2014-08-02 17:18:57 UTC
Permalink
Raw Message
I generally only build once a week. And it is usually just an update.

Occasionally, this fails, usually because enough changes have
accumulated to put it out of whack. Last night, for example, it failed
because it couldn't find resdll (DOS version). Examining the list of
prior output lines showed that some of the pre-compiled headers no
longer matched the actual headers.

So I did what I usually do in these cases: a "builder clean" followed
by the build command file in the ow directory, which did a full build.

Or rather, which /would/ have done a full build had it not stopped
with the same problem.

Since I didn't see the log files don't appear to be present (the
netbook screen isn't that big, and it doesn't have a full keypad, so
some things don't work as well as on a full-sized computer), I am
rebuilding. One thing I noticed is that some things /are being built/,
which seems strange, as I would have expected them to have been built
last night in the full build like everything else in their immediate
vicinity.

The prebuild headers appear to have been prebuilt; at least, I am not
seeing any warnings about them.

Here are the details on the problem, as I see it here ( the "<...>"
stands for the path from the drive root to the repository directory):
Directory: <...>\bld\vi\dos286.ovl
Command: wlink ... name vi.exe ... a whole lot of OBJ files followed
by:

end lib <...>\bld\rcsdll/dosi86/resdll

and the error message: cannot open <...>\bld\rcsdll/dosi86/resdll.lib:
no such file or directory.

This is, of course followed by a lot of "undefined reference" and
"undefined symbol" messages, as one would expect if an entire DLL
can't be found by the linker.

Going to <...>\bld\rcsdll/dosi86, I find the makefile -- and nothing
else.

Summary:

1) It seems very odd that changes in the header files do not prompt
recreation of the precompiled header files. I thought the whole
/point/ of make was to keep everything up-to-date.

2) I can, of course, manually do wmake in <...>\bld\rcsdll/dosi86 and
try again. And, indeed, I just did so. Eventually, no doubt, I will
get a full build, or a problem I cannot solve, for example, a compiler
option problem.

3) It does seem strange, however, that something would be called for
/before it has been created/.
--
"Nature must be explained in
her own terms through
the experience of our senses."
Hans-Bernhard Bröker
2014-08-03 15:07:29 UTC
Permalink
Raw Message
Post by Paul S. Person
I generally only build once a week. And it is usually just an update.
Occasionally, this fails, usually because enough changes have
accumulated to put it out of whack. Last night, for example, it failed
because it couldn't find resdll (DOS version). Examining the list of
prior output lines showed that some of the pre-compiled headers no
longer matched the actual headers.
The primary problem though is that rcsdll itself just isn't built for
that target (dosi86).
Post by Paul S. Person
Going to <...>\bld\rcsdll/dosi86, I find the makefile -- and nothing
else.
As of #37540, that should be different.
Post by Paul S. Person
3) It does seem strange, however, that something would be called for
/before it has been created/.
The problem actually isn't that something would be built too late ...
it's not built _at_all_. Fixed.
Paul S. Person
2014-08-03 16:26:05 UTC
Permalink
Raw Message
On Sun, 03 Aug 2014 17:07:29 +0200, Hans-Bernhard Bröker
Post by Hans-Bernhard Bröker
Post by Paul S. Person
I generally only build once a week. And it is usually just an update.
Occasionally, this fails, usually because enough changes have
accumulated to put it out of whack. Last night, for example, it failed
because it couldn't find resdll (DOS version). Examining the list of
prior output lines showed that some of the pre-compiled headers no
longer matched the actual headers.
The primary problem though is that rcsdll itself just isn't built for
that target (dosi86).
Post by Paul S. Person
Going to <...>\bld\rcsdll/dosi86, I find the makefile -- and nothing
else.
As of #37540, that should be different.
Post by Paul S. Person
3) It does seem strange, however, that something would be called for
/before it has been created/.
The problem actually isn't that something would be built too late ...
it's not built _at_all_. Fixed.
Well, "never" is pretty late.

I just started my fourth or fifth attempt and saw the changed makefile
received.

I am having to make several attempts because Windows 7's cmd box
apparently hangs after "enough" text has been output. This was all
discussed years ago when I first tried building on my netbook. For
some reason this is affecting viper.

Thanks. This should be affecting all full builds, so it should help a
lot of build servers, and mine the next time I am forced to do a full
build.
--
"Nature must be explained in
her own terms through
the experience of our senses."
Hans-Bernhard Bröker
2014-08-03 18:37:11 UTC
Permalink
Raw Message
Post by Paul S. Person
I am having to make several attempts because Windows 7's cmd box
apparently hangs after "enough" text has been output.
I don't think the raw amount of text really has anything to do with it.
I've had completed build runs with longer log files (and thus mor
screen output, too) than those which did hang.

E.g. I did a rebuild of everything while analyzing the problem at hand.
It failed in vi\dos286.ovl after 3.4 MB of screen / log file output.
The incremental build after that hung itself up after about a fifth of
that output size. The next increment output even less, befor hanging.

I'm convinced it's that ancient DOS binary wgml.exe being run in a
virtual DOX machine that's really causing this. One way or another it
exhausts the NTVDM.exe process, which then eats CPU like crazy, while
sitting there doing nothing useful.

If memory serves, a clean, full rebuild of everything, but without the
docs (i.e. DOC_BUILD=0) terminates correctly. A partial build of just
the docs, doesn't.
Paul S. Person
2014-08-04 16:36:29 UTC
Permalink
Raw Message
On Sun, 03 Aug 2014 20:37:11 +0200, Hans-Bernhard Bröker
Post by Hans-Bernhard Bröker
Post by Paul S. Person
I am having to make several attempts because Windows 7's cmd box
apparently hangs after "enough" text has been output.
I don't think the raw amount of text really has anything to do with it.
I've had completed build runs with longer log files (and thus mor
screen output, too) than those which did hang.
E.g. I did a rebuild of everything while analyzing the problem at hand.
It failed in vi\dos286.ovl after 3.4 MB of screen / log file output.
The incremental build after that hung itself up after about a fifth of
that output size. The next increment output even less, befor hanging.
That sounds like a /very/ familiar location!
Post by Hans-Bernhard Bröker
I'm convinced it's that ancient DOS binary wgml.exe being run in a
virtual DOX machine that's really causing this. One way or another it
exhausts the NTVDM.exe process, which then eats CPU like crazy, while
sitting there doing nothing useful.
IIRC, wgml is used in some of the builds, even when the docs
themselves are not built. That might explain the "16-bit illegal op"
message box I got after the first time builder completed.
Post by Hans-Bernhard Bröker
If memory serves, a clean, full rebuild of everything, but without the
docs (i.e. DOC_BUILD=0) terminates correctly. A partial build of just
the docs, doesn't.
I don't do the docs with builder; that never works. The hangs are at
or near the location you gave above.

Most bld subdirectories just make a lot of OBJ files and then use the
linker or the librarian once. These, however, use them (or other
programs taking long command lines) multiple times. So one theory
would be that the period "whereami" directory outputs clears things
up, and when too much is done between them, something hangs.

Or you may be right: it may just be that these directories use wgml,
and wgml, being 16-bit (unless you happen to be building on 32-bit
OS/2), is causing the problem, mediated by the Windows 7 DOS session.

One thing this is /not/ is a tight loop in the program being run. I
have, in working on the reconstructed wgml code, managed to create
those, and nothing short of Task Manager is able to stop them. These
hangs, however, closed when I clicked the "X" button on the window.

And, IIRC, I /never/ got a full build including the docs out of
Windows 7. Which is why my batch file for the weekly update builds
does this:

1) it does a sync
2) it does builder (excluding the docs)
3) it goes into each doc directory in turn in the proper order (PS
before PDF, normal Windows help before HTML Windows help) and runs
wmake
4) it waits for me to acknowledge the output from step three, and then
lists the build.log to the terminal
5) it waits for me to finishing viewing the log and then closes the
window

Since the docs almost never change, and "builder clean" doesn't
affect their directories, nothing much happens in step 3.

Or, usually, in step 2 either -- there haven't been that many changes
lately.
--
"Nature must be explained in
her own terms through
the experience of our senses."
Hans-Bernhard Bröker
2014-08-04 22:05:21 UTC
Permalink
Raw Message
Post by Paul S. Person
On Sun, 03 Aug 2014 20:37:11 +0200, Hans-Bernhard Bröker
That sounds like a /very/ familiar location!
That's because the build was _broken_ in that location. Now it's fixed,
and I did check: the full build w/o docs completed successfully, at
least on this here Windows box. 3.7 MB of log file, no hangups.
Post by Paul S. Person
Or you may be right: it may just be that these directories use wgml,
and wgml, being 16-bit (unless you happen to be building on 32-bit
OS/2), is causing the problem, mediated by the Windows 7 DOS session.
One can actually see the problem happening with a tool like
ProcessExplorer. Every time wgml.exe runs, the ntvdm.exe process is
left with another four open, probably orphaned handles into the "WoW"
subsystem. There more of these there are, the slower it all gets. The
telltale for me is that ntvdm.exe starts consuming kernel-mode CPU
cycles like crazy. At some point, ntvdm.exe ends up just sitting there
busy looping (apparently in some function called cmdCheckTemp), eating
up one entire core's worth of CPU time, but doing, effectively, nothing
at all.

Stopping and restarting "builder" in the docs directory once this has
happened doesn't really help, either. I assume that's because it
re-uses the same instance of ntvdm.exe, which still has all those
orphaned handles sitting around. You really have to kill ntvdm.exe, or
close the cmd.exe session that this was all run from, to get a proper
fresh start.
Post by Paul S. Person
Since the docs almost never change, and "builder clean" doesn't
affect their directories, nothing much happens in step 3.
Under these conditions even a plain builder run including docs would
just work, because it doesn't run wgml.exe all that often.
Paul S. Person
2014-08-05 23:38:46 UTC
Permalink
Raw Message
On Tue, 05 Aug 2014 00:05:21 +0200, Hans-Bernhard Bröker
Post by Hans-Bernhard Bröker
Post by Paul S. Person
On Sun, 03 Aug 2014 20:37:11 +0200, Hans-Bernhard Bröker
That sounds like a /very/ familiar location!
That's because the build was _broken_ in that location. Now it's fixed,
and I did check: the full build w/o docs completed successfully, at
least on this here Windows box. 3.7 MB of log file, no hangups.
As to the first point, I think I confused myself on what location was
in question. My bad.

As to the second, I should have said "on my Windows 7 netbook". It is
on that device that no full build including the docs has ever
successfully completed, hence my CMD file doing the docs separately.
--
"Nature must be explained in
her own terms through
the experience of our senses."
Loading...