onn@utgpu.UUCP (09/07/87)
Well, through the help of the net, I finally got the program to link
without giving me the "segment exceeds 64k" message. The problem was
that all intialized and static data gets placed into the default data
segment _DATA, which cannot exceed 64k (thanks greg@gryphon). Well this
program had alot of strings (static data) and Greg suggested to use the
(undocumented) option -Gt#, where # is any number. This places all data
objects that are greater than # in size into their own segment. I used a
value of 4 here. This has the effect of removing all the strings from
the default data segment.
This seems to have worked. But now I have another problem:
Fixup overflow near 008b in segment PREPROC_TEXT in /lib/Llibc.a(signal.o)
offset 262d8H
It seems that many of the LIBRARY routines use PREPROC_TEXT for their text
segment name. I'm not up on how fixups work (but I know what they are), and
so cannot see what to do here.
Does any one have any more suggestions for me.
Thanks in advance,
Brian.
--
--------------
Brian A. Onn
University of Toronto Computing Services
Erindale College
...{utzoo, ihnp4, decvax}!utcs!onnrap@oliveb.UUCP (Robert A. Pease) (09/08/87)
In article <1987Sep7.051456.1836@gpu.utcs.toronto.edu> onn@gpu.utcs.toronto.edu (Brian Onn) writes: | |Well, through the help of the net, I finally got the program to link |without giving me the "segment exceeds 64k" message. |.... Greg suggested to use the |(undocumented) option -Gt#, where # is any number. This places all data |objects that are greater than # in size into their own segment. | |-------------- |Brian A. Onn |University of Toronto Computing Services |Erindale College |...{utzoo, ihnp4, decvax}!utcs!onn I don't want to be too picky here but the 'Gt' switch is documented in the MSC User's guide. Section 9.13 on page 206 (which is listed in the index) is devoted to the 'Gt' switch and its use. The switch is also summarized in Appendix B.2.1 (page 275) summarizing MSC options and referenced in Appendix C.5 (page 298) summarizing XENIX compatibile options for CL. Just trying to clear some things up. Hope I helped. -- Robert A. Pease {hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!olivej!rap
greg@gryphon.CTS.COM (Greg Laskin) (09/09/87)
In article <1987Sep7.051456.1836@gpu.utcs.toronto.edu> onn@gpu.utcs.toronto.edu (Brian Onn) writes: > >This seems to have worked. But now I have another problem: > >Fixup overflow near 008b in segment PREPROC_TEXT in /lib/Llibc.a(signal.o) > offset 262d8H > This is the result of a bug in the SCO SV 286 2.1.3 Large model library. It may or may not be present in other versions of Xenix. A fixup overflow occurs when the linker attemps to resolve an external reference by adding an relocation bias to an offset and get a result that exceeds 65535. In 2.1.3 Large model library, signal.o contains a NEAR call to an EXTERNAL routine. The external routine in resolved in the header files that are always included by the linker prior to the modules you specify on the command line. Thus the external routine (I believe it's loadds()) is always in the first CODE segment. If the program has more than one code segment, signal.o usually does NOT end up in the first code segment since its in the library and is loaded after all the modules specified in the comand line. The fixup overflow occurs when the resulting intersegment call from the signal module can't be resolved because it needs to be a far call. The work-around: 1. Extract signal.o from the Large model library. ar x /lib/Llibc.a signal.o 2. Load signal.o prior to loading other program modules to assure it ends up in the first code segment. cc -<switches> signal.o ${OBJS} To see the command lines issued to the various passes of the compiler and linker by cc, use -d switch. to loadds from signal cannot be resolved with a >It seems that many of the LIBRARY routines use PREPROC_TEXT for their text >segment name. I'm not up on how fixups work (but I know what they are), and >so cannot see what to do here. > >Does any one have any more suggestions for me. > >Thanks in advance, > Brian. > >-- >-------------- >Brian A. Onn >University of Toronto Computing Services >Erindale College >...{utzoo, ihnp4, decvax}!utcs!onn -- Greg Laskin "When everybody's talking and nobody's listening, how can we decide?" INTERNET: greg@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4}!crash!gryphon!greg UUCP: {philabs, scgvaxd}!cadovax!gryphon!greg
chips@usfvax2.UUCP (Chip Salzenberg) (09/09/87)
Brian Onn writes: > > But now I have another problem: > > Fixup overflow near 008b in segment PREPROC_TEXT in /lib/Llibc.a(signal.o) > offset 262d8H > -------------- > Brian A. Onn > University of Toronto Computing Services I had the same problem. I fixed it by extracting signal.o from the C library and linking it by name: ar x /lilb/Llibc.a signal.o # extract signal object file mv signal.o Lsignal.o # rename: "Large" signal ...then add `Lsignal.o' to your ld (or final cc) command. Note that it only worked for me when `Lsignal.o' was the _first_ object file linked. -- Chip Salzenberg UUCP: "uunet!ateng!chip" or "chips@usfvax2.UUCP" A.T. Engineering, Tampa Fidonet: 137/42 CIS: 73717,366 "Use the Source, Luke!" My opinions do not necessarily agree with anything.
brian@ncrcan.UUCP (Brian Onn) (09/11/87)
In article <4777@oliveb.UUCP> rap@olivej.UUCP (Robert A. Pease) writes: ]In article <1987Sep7.051456.1836@gpu.utcs.toronto.edu> onn@gpu.utcs.toronto.edu (Brian Onn) writes: ]| ]|Well, through the help of the net, I finally got the program to link ]|without giving me the "segment exceeds 64k" message. ]|.... Greg suggested to use the ]|(undocumented) option -Gt#, where # is any number. This places all data ]|objects that are greater than # in size into their own segment. ]| ]|-------------- ]|Brian A. Onn ]|University of Toronto Computing Services ]|Erindale College ]|...{utzoo, ihnp4, decvax}!utcs!onn ] ]I don't want to be too picky here but the 'Gt' switch is documented in ]the MSC User's guide. Section 9.13 on page 206 (which is listed in ]the index) is devoted to the 'Gt' switch and its use. The switch is ]also summarized in Appendix B.2.1 (page 275) summarizing MSC options ]and referenced in Appendix C.5 (page 298) summarizing XENIX ]compatibile options for CL. ] ]Just trying to clear some things up. Hope I helped. ]-- ] ] Robert A. Pease ]{hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!olivej!rap I don't want to be too picky either, but should I be expected to read the MSC users guide (which didn't come with my Xenix, by the way) to find out about features which MSC C compiler supports, and which they decided to also implement in their Xenix C compiler, but not document?? Give me a break! I'm talking about Xenix here, remember, cc -a -b -c, not MSC /A /B /C or CL /A /B /C.