cig@genrad.UUCP (Charles I. Ganimian Jr.) (12/10/88)
Hello, I have a windows question for those of you who have worked with multiple SEGMENTS in a small model program. I need to split my app up into different segments but the C runtime functions used in the code cause linker errors (L2003 intersegment self-relative fixup) how can I resolve these errors so my app can be split up into different segments. I have many modules which are already locically grouped with their support functions so having some far functions is not a problem. I just don't want the overhead of a medium model program and I don't have any space left in the _TEXT (default code) segment. Any hints would be helpful, I have already put modules that don't have this prob in separate segments with no trouble and I need to split up the app up even more. thanks charlie g. BTW, I am working with SDK 2.1 & C 5.1 if it matters...
vpsingha@athena.mit.edu (Vivek P. Singhal) (12/11/88)
In article <14349@genrad.UUCP> cig@genrad.UUCP (Charles I. Ganimian Jr.) writes: >Hello, > > I have a windows question for those of you who have worked > with multiple SEGMENTS in a small model program. > I need to split my app up into different segments but > the C runtime functions used in the code cause linker > errors (L2003 intersegment self-relative fixup) how can > I resolve these errors so my app can be split up into > different segments. I have many modules which are already > locically grouped with their support functions so having > some far functions is not a problem. When I encountered this error message, I found I was making function calls across object files without using the FAR keyword. If you're able to make function calls within the same object file, but not across different object files, then you probably have the same problem. You should should declare the function as FAR in both its definition object file and in the object file where it is being used. If you need more help with multiple-segment small-model applications, try the Petzold book; I've found it an indispensable reference for such problems. By the way, I found the MSC manual was no help on this problem; i.e. the manual says: L2003 intersegment self-relative fixup An intersegment self-relative fixup is not allowed. Maybe people at Microsoft find these kinds of error messages helpful, but I sure don't :-). Hope this helps... Vivek _____________________________________________________________________________ | Vivek Singhal: vpsingha@athena.mit.edu 474 Memorial Drive | | vivek@newt.lcs.mit.edu Cambridge, MA 02139 | | (617) 225-7576 (617) 621-0405 |
cig@genrad.UUCP (Charles I. Ganimian Jr.) (12/13/88)
>> with multiple SEGMENTS in a small model program. >> I need to split my app up into different segments but >> the C runtime functions used in the code cause linker >> errors (L2003 intersegment self-relative fixup) how can >> I resolve these errors so my app can be split up into > >When I encountered this error message, I found I was making function >calls across object files without using the FAR keyword. If you're >able to make function calls within the same object file, but not >across different object files, then you probably have the same >problem. You should should declare the function as FAR in both its >definition object file and in the object file where it is being used. > >try the Petzold book; I've found it an indispensable reference for > > >Vivek thanks, I knew about making my functions FAR and I will do that but the real problem is the C runtime library functions. I need to use sprintf, atoi, etc and these i cannot modify in a rational manner so that they are far functions. What can I do ... I want to stay with the small model and I am at a point where I can't move forward until I can fix this HELP!!! thanks charlie g NOTE: this article is long winded so news would let me post a follow-up with enough info to be useful...
vpsingha@athena.mit.edu (Vivek P. Singhal) (12/13/88)
In article <14484@genrad.UUCP> cig@genrad.UUCP (Charles I. Ganimian Jr.) writes: > I need to use sprintf, atoi, etc and these i cannot modify > in a rational manner so that they are far functions. What can > I do ... I want to stay with the small model and I am at > a point where I can't move forward until I can fix this According to Petzold (on page 292): "As you can see, this mixed-model approach is more of a headache than the medium-model approach. It requires that you figure out which functions must be declared far and which can be near. It has an additional problem: You can call normal C library routines from only one segment -- the segment that gets the default segment name _TEXT when you compile without the -NT switch." Consequently, its seems that you can use the the standard library functions only from the main object file when using the mixed memory model. You might be able to use the medium model and call the library functions from anywhere, but I haven't tried it. Vivek _____________________________________________________________________________ | Vivek Singhal: vpsingha@athena.mit.edu 474 Memorial Drive | | vivek@newt.lcs.mit.edu Cambridge, MA 02139 | | (617) 225-7576 (617) 621-0405 |
dennis@se-sd.sandiego.ncr.com (Dennis Foster) (12/17/88)
In article <14484@genrad.UUCP> cig@genrad.UUCP (Charles I. Ganimian Jr.) writes: > > thanks, I knew about making my functions FAR and I will do > that but the real problem is the C runtime library functions. > > I need to use sprintf, atoi, etc and these i cannot modify > in a rational manner so that they are far functions. What can > I do ... I want to stay with the small model and I am at > a point where I can't move forward until I can fix this > > It sounds like what you want is to use medium model featues in the small memory model! Why not just switch to the medium model. It really is the best for writing all but the most simple windows applications. In using the medium model for windows apps, you should make all functions called from outside their module of definition FAR (they will be by default) and all functions that are called only within the module they are defined in NEAR (it's even better to make them static NEAR so that you don't accidently call them from somewhere else). Link to the medium model versions of the windows libraries and all your runtime calls will then work (from whatever segment the call was located in). Does this help?
cig@genrad.UUCP (Charles I. Ganimian Jr.) (12/19/88)
In article <1706@se-sd.sandiego.ncr.com> dennis@se-sd.sandiego.NCR.COM (Dennis Foster(AEP)) writes: >It sounds like what you want is to use medium model featues in the >small memory model! Why not just switch to the medium model. It >really is the best for writing all but the most simple windows >applications. > >Does this help? Yes thanks, now for the next question... do I need / want to name and list the segments in the .def file or do the automagically end up LOADONCALL DISCARDABLE thanks again charlie g.
billc@mirror.UUCP (Bill Callahan @ Mirror) (12/20/88)
In article <14794@genrad.UUCP> cig@genrad.UUCP (Charles I. Ganimian Jr.) writes: > > > Yes thanks, now for the next question... do I need / want to > name and list the segments in the .def file or do the automagically > end up LOADONCALL DISCARDABLE > This is a matter of programming style. Personally, I name mine because I don't trust defaults. Actually, 'not trust' is the wrong term. I like to state things explicitly so that when some future programmer inherits my code, he or she won't have to get out a manual to try to figure out what the linker will do. Stating them explicitly also make changing the characterics more straight-forward. I often will make a particular segment be temporarily FIXED during debugging (see my earlier article on the infamous SymDeb INT3 bug.) It's also nice to have a list of what your segments are, rather than forcing someone to go through the makefile to check compiler options to figure out what they are. But do what you like. Bill Callahan billc@mirror.TMC.COM {mit-eddie, pyramid, wjh12, xait, datacube}!mirror!billc Mirror Systems 2067 Massachusetts Ave. 617\661-0777 x149 Cambridge, MA 02140
bturner@hpcvlx.HP.COM (Bill Turner) (12/21/88)
> Yes thanks, now for the next question... do I need / want to > name and list the segments in the .def file or do the automagically > end up LOADONCALL DISCARDABLE If you specify CODE LOADONCALL DISCARDABLE, this is the default for all code segments. You can override this on a segment-by-segment basis by explicitly specifying them. --Bill Turner