Skip site navigation (1) Skip section navigation (2)

Re: BUG #1250: compilation fails in src/backend/storage/lmgr/s_lock.c

From: Aidan Dixon <Aidan(dot)Dixon(at)Blueyonder(dot)co(dot)uk>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1250: compilation fails in src/backend/storage/lmgr/s_lock.c
Date: 2004-09-10 20:53:51
Message-ID: Pine.GSO.4.58.0409102147260.1026@cnyrfgevan (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Fri, 10 Sep 2004, Tom Lane wrote:

>"PostgreSQL Bugs List" <pgsql-bugs(at)postgresql(dot)org> writes:
>> The code in s_lock.c uses a  ".seg" directive where ".section" seems to be
>> in vogue, judging from the output of "cc -S" for a simple "hello world" type
>> program.
>Hmm.  So how can we distinguish your version of Solaris from the ones
>that want ".seg"?

The SUNWspro man page for cc(1) contains the following (entries for -xarch=v9
i.e. 64bit sparc apply in my case)

                      sparc (SPARC)
                      i386 (x86)

          The above are not predefined in -Xc mode.
          These predefinitions are valid in all modes:
                   __`uname -s`_`uname -r`
                   __sparc (SPARC)
                   __sparcv9 (SPARC with -xarch=v9|v9a|v9b)
                   __i386 (x86)
          The following is predefined in -Xa and -Xt modes only:
          The compiler also predefines the object-like macro
          to indicate the pragma will be recognized.

Guess the ___SUNPRO_C macro is a start.  'fraid the only other compiler I can
test against is gcc-3.4.1.   Any suggestions, I'll give 'em a try.


Aidan Thomas Dixon - aidan(dot)dixon(at)blueyonder(dot)co(dot)uk
"Whether you believe you can or you can't, you're probably right!"

In response to

pgsql-bugs by date

Next:From: Bill SchaubDate: 2004-09-10 22:34:18
Subject: Re: BUG #1249: pg_restore doesnt handle restoring databases
Previous:From: Theodore PetroskyDate: 2004-09-10 20:41:21
Subject: Re: problems with OS X and beta 2

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group