Xref: utzoo alt.msdos.programmer:1696 comp.sys.ibm.pc.programmer:1736
Path: utzoo!utgpu!news-server.csri.toronto.edu!neat.cs.toronto.edu!leemc
Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc.programmer
From: leemc@cs.toronto.edu (Matthew Lee)
Subject: Re: TC 2.0 Linking Problems
Message-ID: <90May31.161249edt.14905@neat.cs.toronto.edu>
Organization: Department of Computer Science, University of Toronto
References: <1990May25.134431.25796@jarvis.csri.toronto.edu> <90151.102706P88035@BARILVM.BITNET>
Date: 31 May 90 20:13:45 GMT
Lines: 53

In article <90151.102706P88035@BARILVM.BITNET> P88035@BARILVM.BITNET (Ephraim Vider) writes:
>In article <1990May25.134431.25796@jarvis.csri.toronto.edu>,
>I wrote:
>>
>>Hello Netland,
>>
>>I'm *attempting* to port some code (not written by myself) from MSC 5.1 to
>>TC 2.0 . The code consists of several 'C' source files and one .asm file. When
>>I attempted to link the object code, compiled in large model, I get several
>>error messages of the form:
>>
>>     "Fixup overflow in module FOO.C at FOO_TEXT:XXXX, target = _VARIABLE"
>>
>>Now, all of the "_VARIABLE"'s are global variables declared as PUBLIC in the
>>CODE segment of the assembler file. There are corresponding "extern VARIABLE"
>>declarations in the 'C' files.
>>
>>Anybody have an idea how to fix this? After looking through a few manuals I am
>>none the wiser although I suspect that the tlink is looking for the           s
>>"VARIABLE"'
>>in the DATA segment, not the CODE segment.
>>
>>Sorry if I haven't given enough details, I'm hoping this a problem somebody
>>has seen before and has a straightforward fix.
>>
>>Any suggestions welcome. Thanks!
>>
>
>   Even in large model - Turbo C expects all static data to be in the
>default data segment named _DATA and all offsets to these variables
>are calculated from DGROUP. This apperantly causes problems when
>variables are in another segment.
>
>The way to fix this problem is to declare
>
>        extern int far foo;
>
>in your C code.
>   The far keyword tells the compiler that this variable
>is not in the default data segment.
>   This solution worked for me in a similar situation.
>
>                         Ephraim

Yes, you are right, that's the way its done.  I eventually puzzled it out on my
own after several perusals of various manuals, snooping through generated asm
code etc. Good thing I didn't see your posting a week ago or I wouldn't know
all I do now about segmentation, memory models and all that other fun stuff.

Thanks for your response.

Matt
leemc@csri.toronto.edu