library build issue with openwatcom about orangec

[LADSoft]

Hi Michael,

guess I got discouraged about the time a bug in openwatcom caused it to
generate an executable that locked up the computer, and the executable
subsequently got classified as an antivirus by my antivirus software.
I spent the time to make a workaround for the bug, but I didn't try
compiling the RTL with the resulting code... That bug was really
silly, I just moved a declaration from an inner loop to an outer loop
and things were fine after that...

This seems to be another bug, this time in the openwatcom STL. From what
I can tell by writing a small program to duplicate the issue,
deque::clear() is not freeing memory. I've patched my code to work
around it by replacing the memory-critical clears with pop_back(). And
I checked in the fix, it is in the OASM directory. HOWEVER when I try
to compile the RTL now the openwatcom version of the C compiler crashes
on one of the more complicated C programs in the RTL long before it gets
to the file you were having problems with. Presumably this is due to
changes to the source code I've made over the last week or so.

I can only assume this is yet another bug in openwatcom - I will try my
hand at patching that as well but can't get to it until tomorrow night.

If you are curious I tried compiling the RTL with the MINGW version of
OCC before making the patch and it worked fine :).

David

michg wrote:

Hi David,
at my first tries with the examples, I noticed that my
openwatcom-build did not build the c-libs. Here is the error-message
with "omake library":

buildlib
https://cloud.githubusercontent.com/assets/3878262/5765487/3c4dad14-9cfa-11e4-9b1b-3b297e7e0465.JPG

—
Reply to this email directly or view it on GitHub
#6.

[LADSoft]

Hi Michael,

There was no problem with the compiler, the problem was with OMAKE.

I ended up replacing the 'deque' operations with 'lists' in OASM and
OMAKE, to relieve memory usage problems caused by the openwatcom RTL.
That and one other adjustment in OMAKE for openwatcom's
idiosynchricities fixed it. (It was another case of having to move a
declaration to an outer scope).

I was unable to make the same fix throughout the rest of the source tree
at this time because I had already replaced some vectors with dequeues,
and couldn't migrate them to lists. There has to be a deeper change to
the structure and I am hesitant to make that change at this time. I
don't think it is critical however because none of the other apps should
use deques as intensely as OASM and OMAKE.

Let me know if this is sufficient to close the bug.

David
michg wrote:

Hi David,
at my first tries with the examples, I noticed that my
openwatcom-build did not build the c-libs. Here is the error-message
with "omake library":

buildlib
https://cloud.githubusercontent.com/assets/3878262/5765487/3c4dad14-9cfa-11e4-9b1b-3b297e7e0465.JPG

—
Reply to this email directly or view it on GitHub
#6.

[michg]

Hi David,
thanks for your update. The build of the c-libs is now succesful. But trying to build the samples fails.
I tried bzip2.c and whereis.c. Both result in this error:

[LADSoft]

Hi Michael,

I tried a variety of things but can't immediately duplicate. Can you
help me with further information?

What version of OpenWatcom are you using?

I would like to see the contents of your 'test' directory, also your
'PATH' and 'ORANGEC' environment variables.

Also, is there a version of ORANGEC installed other than what you built?

Another thing, would it be possible for you to go to the command line
and compile whereis.c from there to see what happens?

Thanks,

David

michg wrote:

Hi David,
thanks for your update. The build of the c-libs is now succesful. But
trying to build the samples fails.
I tried bzip2.c and whereis.c. Both result in this error:
olink
https://cloud.githubusercontent.com/assets/3878262/5789244/f8911af6-9e62-11e4-9837-58d01aa459e8.JPG

—
Reply to this email directly or view it on GitHub
#6 (comment).

[michg]

Hi David,
I exported the make file from the GUI and tried omake /p:

[LADSoft]

Hi Michael,

That was enough help to steer me to being able to duplicate both the
linker and the omake bugs. Thanks! I've evaluated the problems and
am working on fixes. These are bugs in my code, nothing to do with
openwatcom per se :).

David

michg wrote:

Hi David,
I exported the make file from the GUI and tried omake /p:
omake
https://cloud.githubusercontent.com/assets/3878262/5790388/ed832ba8-9e95-11e4-8b0a-e74f442ba852.JPG

—
Reply to this email directly or view it on GitHub
#6 (comment).

[LADSoft]

Hi Michael,

Ok I fixed the olink bug, it thought your path was a library because of
the '.L' in the middle of it, and that crashed it.

The first problem you found with running the generated make file - the
crash - was due to considering rules recursive - I've put in a check for
recursive rules to handle that. But the rules shouldn't have been
recursive either - there were problems when you put a make file
somewhere other than in the project directory. I updated OCIDE and
OMAKE for that.

Then when I was doing the retest on building the library I ran into
another openwatcom vagary that I had to work around sigh. It should be
pretty obvious from the diffs what I had to do to work around it...

Thank you for reporting these :)

David

michg wrote:

Hi David,
I exported the make file from the GUI and tried omake /p:
omake
https://cloud.githubusercontent.com/assets/3878262/5790388/ed832ba8-9e95-11e4-8b0a-e74f442ba852.JPG

—
Reply to this email directly or view it on GitHub
#6 (comment).

[LADSoft]

Hi Michael,

I did some further testing with openwatcom and it appears the IDE's
debugger is broken when you compile the IDE with openwatcom. I should
be able to look at that tomorrow night.

David

michg wrote:

Hi David,
I exported the make file from the GUI and tried omake /p:
omake
https://cloud.githubusercontent.com/assets/3878262/5790388/ed832ba8-9e95-11e4-8b0a-e74f442ba852.JPG

—
Reply to this email directly or view it on GitHub
#6 (comment).

[LADSoft]

Hi Michael,

If you are curious the problem with 'debug' mode was that the definition
for TreeView_GetItemRect() in c:\watcom\h\nt\commctrl.h is broken (e.g.
in the watcom header files). I have a fix but I have to do testing of
some other changes I made before I release it. Probably tomorrow night...

David

michg wrote:

Hi David,
I exported the make file from the GUI and tried omake /p:
omake
https://cloud.githubusercontent.com/assets/3878262/5790388/ed832ba8-9e95-11e4-8b0a-e74f442ba852.JPG

—
Reply to this email directly or view it on GitHub
#6 (comment).

[michg]

Hi David,
with the latest update I have successfully built and debuggged the argenv.c example. So I think the issue can now be closed. Thanks a lot for your help.
Michael