amy@TAURUS.BITNET (12/12/88)
I'm trying to link some objectcode and got a link error :
Size of global data area: 88014
link:Error More than 32,768 bytes of global variables : 88014
etc ...
I tried to use the '-ss 100000' option but it did not help (.. should it ..?)
Any one outthere have any idea that could help ?
(I'm using Mac Se with MPW version 2.0.2 )
thanx in advance .
---------------------------------------------------------------------------
Ami Ben-Amram , Systems Programmer ARPANET (best): amy@math.tau.ac.il
BITNET: amy@taurus
Tel-aviv university
School of math&science,
Ramat-aviv,Tel-aviv.
Israel.69978
---------------------------------------------------------------------------bob@accuvax.nwu.edu (Bob Hablutzel) (12/12/88)
>I'm trying to link some objectcode and got a link error : >Size of global data area: 88014 >link:Error More than 32,768 bytes of global variables : 88014 >etc ... >I tried to use the '-ss 100000' option but it did not help (.. should it ..?) >Any one outthere have any idea that could help ? >(I'm using Mac Se with MPW version 2.0.2 ) >thanx in advance . As far as I know, MPW doesn't allow more than 32768 bytes of global variables. It sounds like you probably have a large array allocated in the globals - you might have to use the memory manager and allocate a pointer for these arrays. >--------------------------------------------------------------------------- >Ami Ben-Amram , Systems Programmer ARPANET (best): amy@math.tau.ac.il > BITNET: amy@taurus >Tel-aviv university >School of math&science, >Ramat-aviv,Tel-aviv. >Israel.69978 Bob Hablutzel BOB@NUACC.ACNS.NWU.EDU
earleh@eleazar.dartmouth.edu (Earle R. Horton) (12/14/88)
In article <916@taurus.BITNET> <amy%TAURUS.BITNET@CUNYVM.CUNY.EDU> writes: >I'm trying to link some objectcode and got a link error : >Size of global data area: 88014 >link:Error More than 32,768 bytes of global variables : 88014 >etc ... You have too much space allocated to global variables. Chances are you have some large arrays involved. Try changing large arrays to dynamic storage which you allocate with NewPtr or NewHandle. We went through this about six months ago here. The conclusion was that yes, it is unfortunate that you cannot have more than 32,768 bytes of global variables, but that most of the time you can use dynamic storage to get around this problem. >I tried to use the '-ss 100000' option but it did not help (.. should it ..?) No, this won't help at all. The "-ss" option only refers to the maximum CODE segment size. In fact, the linker usually fails to link large code segments, too, because offsets within the segment will be larger than 32,768 bytes. The only case where I have found this option useful is when the total size of the object modules to be linked is > 32k, but the final linked segment is < 32k. Using "-ss" with a large number in this case prevents the linker from breaking up your code into segments, which is appropriate if you are building a non-application code resource. >Any one outthere have any idea that could help ? >(I'm using Mac Se with MPW version 2.0.2 ) In the aforementioned discussion it came out that MPW v 3.0 WOULD support large data. If this is true, and you can afford the upgrade, then maybe you should get it. Aztec C, by Manx Software Systems, does support large data on the Macintosh, you can get a non-beta version of it now, and it is (mostly) source-code compatible with MPW C. This doesn't help much if you are programming in Pascal, but it might if you are programming in C. Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755 (603) 643-4109 Graduate student.
shebanow@Apple.COM (Andrew Shebanow) (12/14/88)
MPW 3.0 supports global data areas larger than 32K. You can get it from APDA. I should point out though that if your problems are caused by large arrays, you would be better off modifying your source code to use a pointer or handle and allocate the array dynamically. It will make your program faster, and it gets rid of many silly limitations like "No one would ever have more than 1000 rects in a drawing, right?". (Of course, no one would ever accuse Apple engineers of making horrible assumptions like that :-) Andrew Shebanow