🚀 go-pugleaf

In article <1990May25.134431.25796@jarvis.csri.toronto.edu>,
leemc@csri.toronto.edu (Matthew Lee) says:
>
>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

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