[comp.windows.x] Problem with R3 make Sun4, SunOS 3.2

jpfo@mbunix (Otin) (02/07/89)

Have an undefined problem, alloca, when making World and install.
Saw a message about this today/yesterday.
Could someone forward to me, as we are stuck in our installation on
Sun4 with SunOS 3.2 of Xv11r3.
Thanx.
jpfo@mbunix.mitre.org
617/271-2314

djm@lupine.UUCP (Dave Mackie) (02/08/89)

In article <8902062135.AA04548@mbunix.mitre.org>, jpfo@mbunix (Otin) writes:
> 
> Have an undefined problem, alloca, when making World and install.
> Could someone forward to me, as we are stuck in our installation on
> Sun4 with SunOS 3.2 of Xv11r3.


	If you are building X11 R3 on a SUN-4 then you want to be sure to
	check that the file /mumble/x11r3/util/imake.includes/Sun.macros
	has the correct definitions of OSMajorVersion and OSMinorVersion.
	Later in the Sun.macros file the following happens:

	/* define this as you like for server compilation */
	#if SunOSPlatform && OSMajorVersion >= 4
	#define ServerDefines SunWindowsDefines -DINCLUDE_ALLOCA_H
	#else
	#define ServerDefines SunWindowsDefines
	#endif

	The -DINCLUDE_ALLOCA_H causes /usr/include/alloca.h to be included
	when compiling. This file (for a reason someone from SUN would have
	to explain) changes alloca(x) to a call to __builtin_alloca(x)
	when you're compiling on a SPARC architecture.

	Note: the Sun.macros file implies that this fix is only needed if
	you're running SUNOS 4.0 or greater, but you said you were running
	SUNOS 3.2. My guess is that either the Sun.macros file didn't know
	about the SUN-4 version of 3.2 which also needs the alloca fix or
	that someone slipped 4.0 onto your system :-).

						Dave Mackie
						Network Computing Devices

moraes@csri.toronto.edu (Mark Moraes) (02/08/89)

In article <169@lupine.UUCP> djm@lupine.UUCP (Dave Mackie) writes:
>	The -DINCLUDE_ALLOCA_H causes /usr/include/alloca.h to be included
>	when compiling. This file (for a reason someone from SUN would have
>	to explain) changes alloca(x) to a call to __builtin_alloca(x)
>	when you're compiling on a SPARC architecture.

The sparc compiler needs to know about the alloca, presumably because
of optimization and register windows in the sparc.

Gcc can also use __builtin_alloca, and it generates a few inline
instructions to change the frame pointer - the Purdue2.0 fixes include
a patch to os.h to do this; the performance improvement from this
alone is significant, because a lot of the drawing functions in the
server call ALLOCATE_LOCAL and DEALLOCATE_LOCAL a lot.

The sparc compiler doesn't do this, which is a pity. It actually
generates the function call.