Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!pdn!boake2!jc3b21!crash
From: crash@jc3b21.UUCP (Frank J. Edwards)
Newsgroups: comp.unix.xenix,comp.unix.i386
Subject: Re: SCO externs ... too many?
Message-ID: <666@jc3b21.UUCP>
Date: 12 May 89 16:46:44 GMT
References: <5268@sfsup.UUCP>
Distribution: usa
Organization: St. Petersburg Jr. College, FL
Lines: 30

>>In article <631@jc3b21.UUCP> davis@jc3b21.UUCP (William J Davis) writes:
>>>
>>>Experimentation further proved that if the number of externs was reduced
>>>past some unknown threshold, suddenly the problem would vanish! ;-(
>>>
>>>I have a call into SCO, but they say they can't
>>>help unless they can replicate the problem, short of me sending them
>>>5 meg of libraries ( yes, I said 5 meg!)  ;-(

As someone who has since spoken with Bill Davis, here is SCO's interpretation
of the problem and how to "fix" it:

Apparently the linker does not generate storage allocations in the bss
segment of a task (under certain conditions) unless the variable is
initialized (which means, essentially, that it's no longer BSS but DATA).
For example,
	int xyzzy = 0;	/* works fine since space MUST be allocated */
and
	int xyzzy;	/* may not work, although compiles okay */

The "solution" then is to set all of your external variables to some
initialization value.  While this is tedious (to say the least!) is
does not harm the portability of the code.  I would guess that the
size of binary is increased, though...

Aside to Bill:  last I heard you were supposed to get a call from SCO
about a (possibly) fixed ld(1) -- has this happened?

Frank "Crash" Edwards
...!uunet!pdn!jc3b21!crash