103d Subj : Re: bcc 5.02 command line v. ide To : borland.public.cpp.borlandcpp From : David Morris Date : Thu Dec 02 2004 02:44 pm "Ed Mulroy [TeamB]" wrote in message news:41aea0d9$1@newsgroups.borland.com... Firstly Ed, let me thank you for taking the time to reply. > The IDE uses DLL versions of the compiler and linker so does > not use the same physical compiler and linker as a command > line build. Ok, that is scary. It means that in theory we could end up with different object code for from the same source code. > I do not think the C++ option setting have any effect on a C > language build EXCEPT for the runtime type id (RTTI) and > exception handling (EH). I prefer building from the > command line and for C builds I always specify -RT- (RTTI > off) and -x- (EH off) as well as linking with noeh?.lib ('?' > is 1st letter of memory model) or noeh32.lib to stub out any > remaining RTTI and EH found in the libraries. The > difference in executable size from doing that is noticable. I had tried those settings, which did not appear to make any difference, probably because I linked noehl.lib, (this is, unsurprisingly, the large model), for exactly the reason you suggested (exe size). > > My serial comm ISR's always have a trap bit which detects if > the ISR is still active at the beginning of the IS E.If > that happens I do the handshake and then IRET immediately. > (My ISR's are all assembly - none are written in C.) The serial port ISR is some very old code that I (and I rarely do this) recycled from some PD code available on the Net, and then modified to fix a few things and to add handshaking. I am going to have to remember how that part works (I think I did this in 1995 or 96). I vaguely remember having to do something like this elsewhere for DOS since it wasn't re-entrant - but I am getting brain fade now. Any clues? (hint?). [ Actually, I am also looking for some 32bit serial port ISR code, is yours available anywhere? (that would be a double hint? hint?)] > If your code depends upon specifics of where things are > placed into DGROUP with respect to each other you should > consider rewriting it to remove such things. That kind of > thing is a common source of memory being written to when it > shouldn't be. No it is isn't. I meant that, the obj modules might be getting linked in a different order, and thus changing the order of variables in DGROUP, which is why I am seeing the error only when built from my make file. I suspect that somewhere something is being overwritten, but is happens to be over some space that is not being used for anything vital at the time - rather scary when I think about it. I thought that I had long ago resolved any buffer over run errors. [It certainly doesn't leak. I have had a client run the software literally for years without stoping it (when they did it was because the monitor had failed!)] > > As for make files, I find the IDE-generated ones to be too > complex and write my own. Absolutely!!! Mind you I suspect that mine are "write only" as the IDE ones to anyone else. (Though at least I can pretend to understand them.) > > If you have an IDE generated make file then a good place > to start is to do this to capture what is actually being done > without tons of unused macros clouding the picture: > > make -K -n -f filename.mak >somename.txt That is cool idea. However, the IDE make file is too complex even for make! MAKE Version 5.0 Copyright (c) 1987, 1997 Borland International Error: Circular dependency exists in makefile drivers\lib\pabxdrv.lib -> drivers\lib\pabxdrv.lib Copy MAKE0257.@@@ BccW16.cfg TLib C:\WORK\MONTEL\SRC\LIB\assert.lib /0 /E @MAKE0029.@@@ TLib C:\WORK\MONTEL\SRC\LIB\time.lib /0 /E @MAKE0085.@@@ TLib C:\WORK\MONTEL\SRC\LIB\pabxlib.lib /0 /E @MAKE0000.@@@ Fatal: 'pabxdrv.lib' does not exist - don't know how to make it I'll try that with a broken down into an individual projects version, and see what I get. Once again thanks for the reply. regards DM . 0