dicky@postel.UUCP (06/11/87)
I am developing a (very) large C program with the Microsoft C compiler under Xenix 2.0. With the linker I have the following problems: - using the -Gt.. option I sometimes get "too many segments" Can the maximum number of segments be changed or is it a linker limitation?? - Again using the -Gt.. option, I sometimes get "segment exceeds 64k" What can I do about that? And for the Xenix Operating System: When I finally have a linked load file, I sometimes get the message "Not enough core", however we have AT's with Megs of memory. Larger load files sometimes load good, while smaller ones (390k) give this message. Is Xenix OK for such large programs?? Please post. ..!mcvax!philmds!dicky I & E, T & M, MDS Philips Eindhoven
dave@sds.UUCP (06/15/87)
In article <180@postel.UUCP>, dicky@postel.UUCP (dicky) writes: > I am developing a (very) large C program with the Microsoft C > compiler under Xenix 2.0. > > With the linker I have the following problems: > - using the -Gt.. option I sometimes get "too many segments" > Can the maximum number of segments be changed or is it > a linker limitation?? You can override the default number of available segments by doing something like cc <blah blah blah> -link -g=256 or whatever value you need instead of 256. You can have up to 1024 segments (I think). BTW, the "-g" flag to /bin/ld isn't documented anywhere that I could find; doing a strings on /bin/ld showed the -g option which I tried and found to work. > - Again using the -Gt.. option, I sometimes get "segment exceeds 64k" > What can I do about that? What value for the "-Gt" flag are you providing? If it's too large you can quickly fill up the default data segment and get this error. This error is annoying -- it doesn't tell you the segment name or type (data or code) or really anything useful. If you're using large model, it is probably the case that (1) you have a humungous source file that is generating more than 64K of code (*very* doubtful), (2) you have a static/global array that is larger than 64K (more likely). Using the huge model (-Mh) should solve (2), splitting the source file into multiple files should solve (1). In the huge model, arrays may occupy multiple segments but a single data object (e.g., an array element) must fit in a single segment (hopefully, this isn't too restrictive for your needs -- if it is, you're SOL as far as I know). Another remote possibility is that you have the same source file name in multiple directories whose object code get placed in the same library. (E.g., screen/error.c and database/error.c, with the object from both getting placed in "mylib.a"). If the *combined* size of the code from the source files exceeds 64K, you'll get the error you mentioned. You can get around this problem with the -NM or -NT flags to cc. As for the "not enough core" messages, I really don't know. I would note, however, that the size of the executable may not be the amount of core that the program needs. It is possible that the a.out file contains only the information needed to generate a large, unitialized static (and therefore 0-filled) array rather than the array itself. ---------------------------------------- "This isn't a rental car ... it's privately owned."