efowler@milton.u.washington.edu (Eric Fowler) (09/22/90)
I have been fighting a losing battle with the MSC 5.1 linker for several days now. I have some windows code that compiles, links, and executes flawlessly on my computer at work, a standard 386/33 clone. The same code with the same makefile(and the same .rc, .def, .h, and .lib's) fails to link on the Epson Equity 386/20 that I have at home. The error returned by the linker is always "Warning:No stack segment", followed by:"Unresolved external:", and either 23 or 36 functions. The functions it is failing to find all come from the WINDOWS.H file, with the possible exception of '_acrtused'. I have painstakingly proven beyond any doubt that the LIB variable is pointing to the directory containing the libraries(LIBW, SLIBCEW). This was accomplished by: using the explicit paths for the libraries(which gave no change); deliberately introducing an error into the LIB setting(yielding a different error message, "Cannot find libraries:<library names>"); and using different libraries(which gave either more or less functions unresolved). Needless to say, I have reinstalled windows, the SDK, and C5.1 many times. Each time I use the same protocol as at work, namely, Emulator math, build the libraries for all memory models, build combined libraries, and install QuickC with the QuickC editor. A call to Microsoft got the suggestion that the installation of MSC 5.1 might have quietly failed due to an environment problem(e.g. a TSR). With that in mind, I copied all the (working) .LIB files from work to floppies and thence to home, and tried again. No dice:no change. I have no TSRs that I know about. I have removed SHARE from my 32 meg disk, have tried this with high memory both loaded and disabled, and with SMARTDRIVE both loaded and disabled. The DOS at work is 3.31, at home is 3.30. All compiling is done from the DOS environment-windows is not loaded(exceptions below). My config and autoexec files are studies in simplicity, simply setting up COMSPEC=command.com, shell=command.com /p /e:1024, files=20, buffers=30, break=on. Some possibly relevant facts: (1) The computer is not on the approved hardware list for windows 3. Just the same, I have been able to run windows in Enhanced mode(not standard or real), and all the linking is done in DOS/conventional memory. (2) I have the MKS toolkit installed, a psuedo-unix shell for PCs. The MKS shell comes with its own UNIX compatible MAKE utility. I have rewritten the makefile for the MKS make, come up under MKS, and had the same failure as when I boot from a DOS floppy and use the Microsoft MAKE. Under those conditions, no part of the MKS toolkit is in memory. (3) I cannot be certain that there is no math coprocessor installed at home(there is none at work). Microsoft tech support assures me that that should not be a problem with the Emulator package, which is what I am using. None of the libraries contain the digit '7' which appears in the coprocessor libraries. (4) Video is standard windows VGA.DRV at work, Video7 Vega 640x480 Version 1.47 at home. This package dates back to 1987. I am nearly out of solutions. I could call Epson for help, but most hardware vendors will tell you that you have a software problem. I could fasten a rope around the computer, tie one end around my neck, and dive into deep water, but this will still not resolve the problem with the linker. If anybody has any better ideas I would love to hear about it. Thank You, =Eric Fowler