patch for sun workshop compilation bug

hello,

i've attached a patch for the following bug
report:

http://archives.postgresql.org/pgsql-ports/2004-09/msg00008.php

in essence, if configure detects that the
environment is sunos4, s_lock.c should use the
.seg opcode. otherwise, s_lock.c should use
.section.

i've tested this and i've gotten the latest CVS
source to compile under Solaris 9 using sun's
compiler.

-ayan

Index: src/backend/storage/lmgr/s_lock.c
===================================================================
RCS file: /projects/cvsroot/pgsql/src/backend/storage/lmgr/s_lock.c,v
retrieving revision 1.33
diff -c -r1.33 s_lock.c
*** src/backend/storage/lmgr/s_lock.c 18 Dec 2004 22:12:52 -0000 1.33
--- src/backend/storage/lmgr/s_lock.c 29 Dec 2004 15:48:01 -0000
***************
*** 240,247 ****
--- 240,254 ----
tas_dummy() /* really means: extern int tas(slock_t
* *lock); */
{
+
+ #ifdef SUNOS4
asm(".seg \"data\"");
asm(".seg \"text\"");
+ #else
+ asm(".section \"data\"");
+ asm(".section \"text\"");
+ #endif
+
asm("_tas:");

/*
Index: src/template/sunos4
===================================================================
RCS file: /projects/cvsroot/pgsql/src/template/sunos4,v
retrieving revision 1.3
diff -c -r1.3 sunos4
*** src/template/sunos4 9 Oct 2003 03:20:34 -0000 1.3
--- src/template/sunos4 29 Dec 2004 15:48:03 -0000
***************
*** 0 ****
--- 1,7 ----
+ if test "$GCC" != yes ; then
+ CC="$CC -Xa" # relaxed ISO C mode
+ CFLAGS="-v -DSUNOS4" # -v is like gcc -Wall
+ if test "$enable_debug" != yes; then
+ CFLAGS="$CFLAGS -O" # any optimization breaks debug
+ fi
+ fi

ayan(at)ayan(dot)net writes:
> in essence, if configure detects that the
> environment is sunos4, s_lock.c should use the
> .seg opcode. otherwise, s_lock.c should use
> .section.

> i've tested this and i've gotten the latest CVS
> source to compile under Solaris 9 using sun's
> compiler.

Applied, except I made the #define symbol be SUNOS4_CC. The original
SUNOS4 seems a tad too likely to be floating around in the standard
compilation environment, which would risk breaking gcc builds.

regards, tom lane