At 01:32 AM 2/13/2003, Sebastian Bergmann wrote: > ... yields strange error messages for each "Creating Version Resource" > build step: > > 16-Bit-MS-DOS-Subsystem: > vcspawn.exe: > The NTVDM-CPU detected an illegal instruction. > > What's this about?
No good, that's for certain. I read somewhere about broken rebase.exe binaries distributed with the psdk. If you ordered your path or IDE exe directories list to run the PSDK's bin over the VC's bin directory, try renaming your PSDK's bin\rebase.exe to rebase-broke.exe and see if that fixes this bug. Oh, you probably have a port of which. Try which rebase.exe and which rebase.com to see what you come up with. The only other command in that list is a simple echo. rebase -q -i "./os/win32/BaseAddr.ref" -x ".\Release" $(InputPath) echo rebased > ".\Release\libhttpd.dbgmark" The rebase command either uses -i to search the given file for the full name of the binary given as $(InputPath) ... e.g. "libhttpd.dll", so we added extensions to the whole list in os/win32/baseaddr.ref. [/me mumbles something about perhaps slashes v.s. backslashes? But then Apache.exe, htpasswd.exe etc wouldn't emit that vcspawn error since those use -b 0x00400000 rather than the -i option.] And last note, I will be committing a mass change of all .dbgmark extensions to .dbx, shorthand for dbg e'x'tracted, because libx.dbg and libx.dbgmark happen to have the same short name :-( [Again, /me wonders if that long extension and a shell command are tripping up your vcspawn.] The only reason we use a mark file is that extracting debug symbols also touches the binary itself, and it seems the date stamp of the .dbg is often slightly older than the binary once rebase.exe has finished writing and closed them both. We don't want to trigger another rebase until new binaries are written. Bill
