dkp@hadron.UUCP (David K. Purks) (06/22/86)
I recently purchased a copy of Version 3.0 of the Microsoft compiler (which includes Version 3.4 of LINK) and have run into a very strange problem. I can't make LINK find external subroutines in modules or libraries which were not compiled with this compiler. Specifically, I have the GREENLEAF C function library and WINDOWS (public domain version). When I reference functions contained in either of these libraries, LINK is very happy to inform me that they are unresolved externals. I have concluded that it is NOT the linker's fault (I've relinked modules compiled with the old compiler with the new LINK and everything's fine). I have tried the -u and -Zl switches on the compiler to prevent it from putting default library names in the .OBJ header. I have also tried extracting the object modules from the libraries and linking these directly as well as building new libraries. I do not have the source for these routines. At this point, I've run out of ideas. Suggestions (even "give up", if appropriate) would be greatly appreciated. If it's not possible to do, I would just like to know why. Please e-mail suggestions and information directly to me and I will post a summary. Thanks in advance. Dave Purks ..!seismo!hadron!dkp
kumar@hpcea.HP (Arvind Kumar) (06/24/86)
External routine names, like mix(), must actually be defined in the external library file as beginning with an underscore, as in _mix proc near etc. Greenleaf will provide MS C 3.00 compatible libraries, you just have to specify it when ordering. If you are calling routines you wrote yourself, remember the leading underscore. Also, C is case sensitive, so be sure to tell the assembler/compiler to preserve case in procedure names. Arvind Kumar ...!hplabs!kumar
parris@itcatl.UUCP (Parris Hughes) (06/26/86)
In article <445@hadron.UUCP>, dkp@hadron.UUCP (David K. Purks) writes: > ... Specifically, I have the GREENLEAF C > function library and WINDOWS (public domain version). ... > > Dave Purks > ..!seismo!hadron!dkp Which reminds me... Has anyone out there using WINDOWS.LIB experienced any problems with it? I had some strange things happen when using it on my last PC based micro project and eventually ended up rewriting the routines that I had used from it. Specifically, the WINDOWS.LIB I am speaking of contained OPEN_WINDOW, CLOSE_WINDOW, LOCATE_WINDOW, SCROLL_WINDOW, CLS_WINDOW, PRINT_WINDOW, BOX, MINOR_BOX, and some others. Am I alone here? Thanks ....gatech!itcatl!parris Parris