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

Re: solaris build problem with Sun compilers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: stange(at)rentec(dot)com, pgsql-ports(at)postgresql(dot)org
Subject: Re: solaris build problem with Sun compilers
Date: 2006-05-11 23:48:08
Message-ID: 18615.1147391288@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-ports
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Well, that's an interesting point ... I wonder what the version in
>> s_lock.c is used for at all?  Maybe it's dead code.

> I think the big question is what uses tas_dummy().  I only see it
> referenced in s_lock.c.

tas_dummy, per se, isn't used at all.  Notice it's declared static
so it couldn't possibly be referenced from anywhere else.  The actually
exported symbols are the labels declared in the assembly code.

And the thing that is striking is that while the other two tas_dummy asm
sections make a point of saying .global or equivalent, there isn't any
such declaration in this one.  Which is why I'm thinking it's dead
code.  Unless the sparc assembler has the unlikely convention that
symbols are global by default, there's no way to reference this.

Alan, could you try removing the __sparc code entirely from s_lock.c
and see if it still works on all those Solaris versions?

			regards, tom lane

In response to

pgsql-ports by date

Next:From: Alan StangeDate: 2006-05-12 00:26:33
Subject: Re: solaris build problem with Sun compilers
Previous:From: Bruce MomjianDate: 2006-05-11 23:34:18
Subject: Re: solaris build problem with Sun compilers

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