Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!dayton!rosevax!sds!dave From: dave@sds.UUCP Newsgroups: comp.unix.xenix Subject: Re: Questions about developing with C under Xenix Message-ID: <416@sds.UUCP> Date: Mon, 15-Jun-87 16:54:53 EDT Article-I.D.: sds.416 Posted: Mon Jun 15 16:54:53 1987 Date-Received: Thu, 18-Jun-87 01:36:26 EDT References: <180@postel.UUCP> Organization: SciCom Data Services, Minnetonka, MN Lines: 49 Keywords: Microsoft C, segments, problems 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 -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."