• C

how to solves these errors? use borland c 3.1 .

compiling  my project don't appear any errors ,but linking my project appear tow errors.
 the errores :

linker Error:Fixup overflow at _TEXT:015E,targer = _OSStartHighRdy in module
UCOS_II.C
linker Error:Fixup overflow at _TEXT:015E,targer = _OSIntCtxSw in module
UCOS_II.C
LVL 1
lmphpAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Kent OlsenData Warehouse Architect / DBACommented:

Hi lmphp,

The Turbo C 3.x library doesn't contain these two routines.  They have names that suggest that they are communications related, so you're probably not linking from the correct library or the names have been misspelled.

Kent
0
PaulCaswellCommented:
Take Kents advice first but if that doesn work (perhap these functions ARE there):

Fixup overflow usually means that a segment has broken a 64K limit. Try generating a .MAP file using linker parameters (I dont know the Borland ones but the Microsoft ones use /MAP). With this MAP file you may be able to see which segment needs splitting.

Paul
0
Kent OlsenData Warehouse Architect / DBACommented:

Paul's right.  Those modules exist, or you'd get "unsatisfied external" errors.

Generate a loadmap and check it.  The Text segment (code segment) is probably more than 64K.

Depending on a LOT of different things, you might be able to get around this by using the HUGE memory model, or performing any of several "tricks".

Basically, you've got a huge program that you want to run in a 16-bit world.  You might have to get very creative.

Kent
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Get Cisco Certified in IT Security

There’s a high demand for IT security experts and network administrators who can safeguard the data that individuals, corporations, and governments rely on every day. Pursue your B.S. in Network Operations and Security and gain the credentials you need for this high-growth field.

Julian HansenCommented:
I think Kdo is close on this one. From what I remember of my Borland days was the memory module you chose to compile under was very important when it came to linking. Selecting large or huge had certain ramifications when it came to declaring functions and variables - you need to specify the pointers as large or huge so they would work across segment boundaries.

I cannot remember enough to give you an exact solution but I would start by looking at your memory modle and work from there.
0
grg99Commented:
"Fixup overflow" is a hard problem to fix.   Sometimes it's due to a symbol being defined into the wrong segment.  Then when the linker tries to define the symbol, the value overflows the segment.  

The problem *might* be that somewhere "_OSStartHighRdy" and "_OSIntCtxSw" are defined as externals, either as "NEAR" externals or not explicitly as "FAR" externals.   Or they're not declared into their own "combine type", or accidentally declared into the main "CODE" combine type.
Then later on the linker tries to cram the code of those routines into the default CODE segment, and they won't fit.

The fix is to carefully read the instructions for using those routines.  The writers probably ran into the same problem, and if they're nice they documented how to get things to work, either with an explicit "FAR" somewhere, or a special linker directive to place the extra code in its own segment.


0
PaulCaswellCommented:
I think your first step is as greg suggests. Look for any any linker directives in the suppliers documentation.

If this doesnt help, try building your package in the 'huge' model. This is the only one that allows for multiple code segments.

After that you're in the realm of massaging the build process.

The quickest answer, if it works, is to look for static data that may be being installed in your code segment. With the Microsoft compilers you can use /Gt32 (or less) to make static data larger than the specified value go into a data segment. I dont know if there is an equivalent in the borland system.

Next, try to find code that is unnecessary. You may have an excess of debug code. There are techniques for making debug completely disappear at release time. Use of one of those along with removing some rarely used code from the debug version can often provide a stop-gap solution.

Has anything we have suggested worked? Get back to us, even if its to say you've solved the problem.

Paul
0
lmphpAuthor Commented:
thanks all of you !
the problems was solved. when i used another compiler , these codes worked very well.
may be I should split those codes to all of you for thanks!
0
lmphpAuthor Commented:
thanks all of you !
the problems was solved. when i used another compiler , these codes worked very well.
may be I should spilt those codes to all of you for thanks!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C

From novice to tech pro — start learning today.