Opened 12 years ago

Closed 12 years ago

#52 closed defect (wontfix)

build error

Reported by: abwillis Owned by: somebody
Priority: major Component: basedrv
Version: Keywords:
Cc:

Description

I do not believe this is a problem in the code but something odd in the environment here. I am only opening a bug here because the build failure caused me to find a few things that I am putting some diffs up for. I have been building fine for about 2 weeks when suddenly starting with a changeset between 747 - 750 I got an error building ehci. The other components did not have a problem. I did a clean on all components and now most of them have the problem and ehci earlier in the process than it had been before the clean (which means if it was a changeset that actually caused it then it could have been a change prior to the ones above but not many before as I had only not done a clean for a few changesets). I do not see any changesets that could have produced the error (I'll post that subsequently) but have no idea why it suddenly started.

Attachments (2)

diff.txt (3.8 KB ) - added by abwillis 12 years ago.
ehci diff... corects use of a prototype error and some nested comments and no newline at end of file warnings in Watcom
makdiff.txt (2.5 KB ) - added by abwillis 12 years ago.
Makefile changes to show build environment difference also including the -Fc mentioned in the ticket

Download all attachments as: .zip

Change History (9)

by abwillis, 12 years ago

Attachment: diff.txt added

ehci diff... corects use of a prototype error and some nested comments and no newline at end of file warnings in Watcom

comment:1 by abwillis, 12 years ago

The error shown below is in usbd which occurred after doing a clean:

Operating System/2 Program Maintenance Utility
Version 4.00.001 Oct  4 2001
Copyright (C) IBM Corporation 1988-2001
Copyright (C) Microsoft Corp. 1988-1991
All rights reserved.

        masm -MX -T  -I. -Ie:\os2tk45\ddk\base\inc usbsegs.asm;
        lib /nol e:\os2tk45\ddk\base\lib\slibcep.lib *fmemcmp.obj;
        lib /nol e:\os2tk45\ddk\base\lib\slibcep.lib *__AHINCR.obj;
        cl -c -Zlp -G2s -Answ -W3 -nologo -Osegli -B1c1l -B2c2l -B3c3l -I. -Ie:\
os2tk45\ddk\base\h -I..\include -Ie:\os2tk45\ddk\base\src\dev\thinkpad\dockii\ap
mcalls -Fc usbconst.c
usbconst.c
        masm -MX -T  -I. -Ie:\os2tk45\ddk\base\inc usbhlp.asm;
        cl -c -Zlp -G2s -Answ -W3 -nologo -Osegli -B1c1l -B2c2l -B3c3l -I. -Ie:\
os2tk45\ddk\base\h -I..\include -Ie:\os2tk45\ddk\base\src\dev\thinkpad\dockii\ap
mcalls -Fc usbidc.c
usbidc.c
usbidc.c(692) : fatal error C1013: cannot open source file 'e:/os2tk45/ddk/base/
h\os2def16.h'
NMAKE : fatal error U1077: 'D:\UTILS\4OS2\4OS2.EXE' : return code '2'
Stop.

One thing I noted was that it is not a source file but rather an include file... The file is there and it can be opened in an editor (in fact I copied it out, deleted it and created a new file and copied and pasted the stuff back in... as well as then trying to copy the original back to no help). I ran a chkdsk and found no problems. Finally, I removed the -Fc and if I do that then all components will build fine except ehci which then gets past its initial error but comes to a new one along the same lines.

comment:2 by abwillis, 12 years ago

This may have been the original error I saw before doing a clean... I really did not pay close enough attention when I first got the error, I had expected either a clean to fix it or a simple fix anyhow. However, after doing the clean I got an error on the first file it attempted to build with the same code as above (same file it couldn't open and same line number etc.). Removing the -Fc caused it to get past that error and built many files until I go to this one (note it says include file rather than source file).

Operating System/2 Program Maintenance Utility
Version 4.00.001 Oct  4 2001
Copyright (C) IBM Corporation 1988-2001
Copyright (C) Microsoft Corp. 1988-1991
All rights reserved.

        cl -c -Zlp -G2s -Answ -W3 -nologo -Osegli -B1c1l -B2c2l -B3c3l -I. -Ie:\
os2tk45\ddk\base\h -I..\include -I..\kee16lib -Ie:\os2tk45\ddk\base\src\dev\dasd
\diskh ehctrace.c
ehctrace.c
e:/os2tk45/ddk/base/h\os2def.h(692) : fatal error C1024: cannot open include fil
e 'os2def16.h'
NMAKE : fatal error U1077: 'D:\UTILS\4OS2\4OS2.EXE' : return code '2'
Stop.

All this to say I then compiled with Watcom (haven't got as far as linking to work yet) and found one error and some warning. I have attached a diff... I haven't compiled anything but ehci so far. The error in Watcom may not be a problem in MSC but probably should be corrected the warnings may be more cosmetic than anything else as they do not seem to cause a problem. If someone knows why MSC is throwing these cannot open file errors (I found one German thread that mentioned it but no solution in it that I could find) I would be interested. My best guess is that the path lengths is causing a problem somewhere but why it suddenly became a problem when it was not before I do not understand. Oh, I suppose I should attach a diff of my makefile so that my environment differences can be seen.

Last edited 12 years ago by abwillis (previous) (diff)

by abwillis, 12 years ago

Attachment: makdiff.txt added

Makefile changes to show build environment difference also including the -Fc mentioned in the ticket

comment:3 by abwillis, 12 years ago

DDK path is e:\os2tk45\ddk and USB is contained in an entirely different tree off of root.

in reply to:  3 comment:4 by w.m.brul, 12 years ago

In my build environment on OS/2 Warp 4.0 NL, I get a similar error:

e:/os2ddk/base/h\os2def.h(649) : fatal error C1024: cannot open include file 'os2def16.h'

when I have a windowed dos command prompt active during my build.

Once I close that window that error disappears.

comment:5 by abwillis, 12 years ago

Unfortunately that is not the case here... no Dos prompts going. I had rebooted and tried building fresh off the reboot without launching anything else to make sure nothing else was conflicting. However, checking my config.sys I notice that RUN=D:\MPTN\BIN\VDOSCTL.EXE

is not longer remarked out so I will test that.

comment:6 by abwillis, 12 years ago

It wasn't the vdosctl but it lead me to the actual cause... the vdosctl got added when I added the vswitch from VirtualPC (needed to test something and forgot I had installed it). Removed the vswitch and now it builds fine again. Again, the only reason I opened the ticket here vs. asking about it in a newsgroup or something was for the errors and warnings in Watcom that are more or less still valid in MSC.

comment:7 by Lars Erdmann, 12 years ago

Resolution: wontfix
Status: newclosed

Not a driver problem

Note: See TracTickets for help on using tickets.