Solaris cc compiler on amd: PostgreSQL does not have native spinlock support on this platform
Hello,
I'm trying to compile postgresql and I got this message telling me
to inform you:
"../../../../src/include/storage/s_lock.h", line 806: #error: PostgreSQL
does not have native spinlock support on this platform. To continue the
compilation, rerun configure using --disable-spinlocks. However,
performance will be poor. Please report this to pgsql-bugs@postgresql.org.
This is the configure line i used:
MAKE=gmake CC=/opt/SUNWspro/bin/cc CFLAGS="-xtarget=opteron
-xarch=amd64" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-xtarget=opteron
-xarch=amd64" LDFLAGS="-xtarget=opteron -xarch=amd64" ./configure
--without-readline
If i try this configuration command instead:
MAKE=gmake CC=/opt/SUNWspro/bin/cc CFLAGS="-fast"
CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-fast" LDFLAGS="-fast" ./configure
--without-readline
It compiles but then i get a 32 bit executable which is not what i want.
This is on a solaris 10 with amd processor using the sun forte 11 compilers.
Are there any fix for this?
Thanks.
Pierre Girard <pierre.girard@gerad.ca> writes:
It compiles but then i get a 32 bit executable which is not what i want.
This is on a solaris 10 with amd processor using the sun forte 11 compilers.
Are there any fix for this?
You'd need to do something about adapting src/backend/port/tas/solaris_i386.s
to amd64, and then change the part of s_lock.h that mentions Solaris/386
to also accept x86_64 not just __i386. Also see src/template/solaris
which controls configure's determination of which tas file is needed.
It's possible that the assembly code would work as-is on amd, in which
case you'd just need a one-liner change in s_lock.h and maybe some
adjustment of the template file.
Please send a patch if you fix this.
regards, tom lane
Tom Lane wrote:
You'd need to do something about adapting src/backend/port/tas/solaris_i386.s
It's possible that the assembly code would work as-is on amd, in which
case you'd just need a one-liner change in s_lock.h and maybe some
adjustment of the template file.
It doesn't compile with the options to create amd code.
cc -Xa -xtarget=opteron -xarch=amd64 -c solaris_i386.s
Assembler: tas.s
"solaris_i386.s", line 12 : Illegal mnemonic
"solaris_i386.s", line 14 : Illegal mnemonic
"solaris_i386.s", line 15 : Syntax error
"solaris_i386.s", line 17 : Syntax error
"solaris_i386.s", line 26 : Illegal mnemonic
"solaris_i386.s", line 28 : Illegal mnemonic
cc: assembler failed for solaris_i386.s
The same file compiles without those options:
cc -Xa -c solaris_i386.s
Please send a patch if you fix this.
Unfortunately i won't be able to help unless you have some code for me
to try out.
Pierre Girard wrote:
Tom Lane wrote:
You'd need to do something about adapting src/backend/port/tas/solaris_i386.s
It's possible that the assembly code would work as-is on amd, in which
case you'd just need a one-liner change in s_lock.h and maybe some
adjustment of the template file.It doesn't compile with the options to create amd code.
cc -Xa -xtarget=opteron -xarch=amd64 -c solaris_i386.s
Assembler: tas.s
"solaris_i386.s", line 12 : Illegal mnemonic
"solaris_i386.s", line 14 : Illegal mnemonic
"solaris_i386.s", line 15 : Syntax error
"solaris_i386.s", line 17 : Syntax error
"solaris_i386.s", line 26 : Illegal mnemonic
"solaris_i386.s", line 28 : Illegal mnemonic
cc: assembler failed for solaris_i386.sThe same file compiles without those options:
cc -Xa -c solaris_i386.s
Interesting. Seems you have a setup that uses its own assembly source
file in port/tas/solaris_i386.s, rather than using inline C ASM. There
are files for both Sparc and i386 there, and are both used only for the
Sun compiler. Does the Sun compiler not support ASM inlining?
Looking at the error line, it is:
pushl %ebp /save prev base pointer
and then:
pushl %ebx /save prev bx
Looks like it is all documented here:
http://www.x86-64.org/documentation/assembly
Specifically:
Exceptions from this rule are instructions manipulating the stack (push,
pop, call, ret, enter and leave) which are implicitly 64-bit and their
32-bit counterparts are not available anymore, yet their 16-bit
counterparts are. So:
pushl %eax # Illegal instruction
pushq %rax # 1 byte instruction encoded as pushl %eax in 32 bits
pushq %r10 # 2 byte instruction encoded as pushl preceeded by REX.
Looking before that, the 64-bit registers are now prefixed with 'r'
instead of 'e', so what I did was to convert all the long/l assembler
instructions to quad/64-bit/q, and rename the registers to use 64-bit
versions. I also modified the function alignment from 4 to 8, patch
attached. Please give it a try and report back any error lines.
Seems Sun might be interested in geting this working. We don't have an
official Sun contact yet for this project.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Attachments:
/rtmp/difftext/plainDownload+26-26
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Looking before that, the 64-bit registers are now prefixed with 'r'
instead of 'e', so what I did was to convert all the long/l assembler
instructions to quad/64-bit/q, and rename the registers to use 64-bit
versions. I also modified the function alignment from 4 to 8, patch
attached. Please give it a try and report back any error lines.
Surely that breaks it for the i386 case --- don't we need a separate
solaris_x86_64.s source file?
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Looking before that, the 64-bit registers are now prefixed with 'r'
instead of 'e', so what I did was to convert all the long/l assembler
instructions to quad/64-bit/q, and rename the registers to use 64-bit
versions. I also modified the function alignment from 4 to 8, patch
attached. Please give it a try and report back any error lines.Surely that breaks it for the i386 case --- don't we need a separate
solaris_x86_64.s source file?
Yes, it is only for him to test. But his email bounced back so it is
possible he isn't going to be back. :-(
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Sat, Dec 17, 2005 at 04:59:45PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Looking before that, the 64-bit registers are now prefixed with 'r'
instead of 'e', so what I did was to convert all the long/l assembler
instructions to quad/64-bit/q, and rename the registers to use 64-bit
versions. I also modified the function alignment from 4 to 8, patch
attached. Please give it a try and report back any error lines.Surely that breaks it for the i386 case --- don't we need a separate
solaris_x86_64.s source file?Yes, it is only for him to test. But his email bounced back so it is
possible he isn't going to be back. :-(
Sorry, I don't remember the history of this thread, but I do have access
to solaris on an opteron if something needs to be tested.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote:
On Sat, Dec 17, 2005 at 04:59:45PM -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Looking before that, the 64-bit registers are now prefixed with 'r'
instead of 'e', so what I did was to convert all the long/l assembler
instructions to quad/64-bit/q, and rename the registers to use 64-bit
versions. I also modified the function alignment from 4 to 8, patch
attached. Please give it a try and report back any error lines.Surely that breaks it for the i386 case --- don't we need a separate
solaris_x86_64.s source file?Yes, it is only for him to test. But his email bounced back so it is
possible he isn't going to be back. :-(Sorry, I don't remember the history of this thread, but I do have access
to solaris on an opteron if something needs to be tested.
If you set up Solaris in 64-bit mode, and are using the Sun compiler,
please test the patch I posted and let me know if it compiles:
http://archives.postgresql.org/pgsql-patches/2005-12/msg00275.php
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073I have applied your patch with only minor comment additions. Let us
know if additional changes are required. Thanks.
Are these flags required to be supplied to configure, or just the ASM
file?
-Xa -xtarget=opteron -xarch=amd64
I am thinking the port isn't 100% fool-proof yet, but it is _much_
closer than it was, and people can now do testing to improve it.
---------------------------------------------------------------------------
Pierre Girard wrote:
Bruce Momjian wrote:
Interesting. Seems you have a setup that uses its own assembly source
file in port/tas/solaris_i386.s, rather than using inline C ASM. There
are files for both Sparc and i386 there, and are both used only for the
Sun compiler. Does the Sun compiler not support ASM inlining?I don't know but i imagine that if the postgresql team decided to do it
that way it's probably not supported.I also modified the function alignment from 4 to 8, patch
attached. Please give it a try and report back any error lines.I applied the patch and now the solaris_i386.s file compiles fine with
the command:
cc -Xa -xtarget=opteron -xarch=amd64 -c solaris_i386.sI made a few changes and was able to compile postgresql completely but i
don't think we'll be trying it until after the holidays. I included
the small changes i made but i'm sure you can make a much better job
than i did.Seems Sun might be interested in geting this working. We don't have an
official Sun contact yet for this project.Given this announcement, i'm surprised that you don't have a contact
already:
http://www.sun.com/smi/Press/sunflash/2005-11/sunflash.20051117.1.htmlHappy holidays everyone.
diff -Naur postgresql-8.1.1/src/Makefile.shlib postgresql-8.1.1.new/src/Makefile.shlib --- postgresql-8.1.1/src/Makefile.shlib Sat Dec 3 15:16:39 2005 +++ postgresql-8.1.1.new/src/Makefile.shlib Fri Dec 23 10:04:58 2005 @@ -193,7 +193,7 @@ ifeq ($(GCC), yes) LINK.shared = $(CC) -shared else - LINK.shared = $(CC) -G + LINK.shared = $(CC) -G $(CFLAGS) endif ifeq ($(with_gnu_ld), yes) LINK.shared += -Wl,-soname,$(soname) diff -Naur postgresql-8.1.1/src/backend/port/tas/solaris_x86_64.s postgresql-8.1.1.new/src/backend/port/tas/solaris_x86_64.s --- postgresql-8.1.1/src/backend/port/tas/solaris_x86_64.s Wed Dec 31 19:00:00 1969 +++ postgresql-8.1.1.new/src/backend/port/tas/solaris_x86_64.s Fri Dec 23 09:17:13 2005 @@ -0,0 +1,33 @@ +/============================================================================= +/ tas.s -- test and set lock for solaris_i386 +/============================================================================= + + .file "tas.s" + .text + .align 16 +.L1.text: + + .globl tas +tas: + pushq %rbp /save prev base pointer + movq %rsp,%rbp /new base pointer + pushq %rbx /save prev bx + movq 8(%rbp),%rbx /load bx with address of lock + movq $255,%rax /put something in ax + xchgb %al,(%rbx) /swap lock value with "0" + cmpb $0,%al /did we get the lock? + jne .Locked + subq %rax,%rax /yes, we got it -- return 0 + jmp .Finish + .align 8 +.Locked: + movq $1,%rax /no, we didn't get it - return 1 +.Finish: + popq %rbx /restore prev bx + movq %rbp,%rsp /restore stack state + popq %rbp + ret /return + .align 8 + .type tas,@function + .size tas,.-tas + diff -Naur postgresql-8.1.1/src/include/storage/s_lock.h postgresql-8.1.1.new/src/include/storage/s_lock.h --- postgresql-8.1.1/src/include/storage/s_lock.h Tue Oct 11 16:41:32 2005 +++ postgresql-8.1.1.new/src/include/storage/s_lock.h Fri Dec 23 09:18:44 2005 @@ -788,7 +788,7 @@/* out-of-line assembler from src/backend/port/tas/foo.s */
-#if defined(__sun) && defined(__i386) +#if defined(__sun) && (defined(__i386) || defined(__x86_64__)) /* * Solaris/386 (we only get here for non-gcc case) */ diff -Naur postgresql-8.1.1/src/template/solaris postgresql-8.1.1.new/src/template/solaris --- postgresql-8.1.1/src/template/solaris Fri Jul 29 13:00:29 2005 +++ postgresql-8.1.1.new/src/template/solaris Fri Dec 23 09:43:08 2005 @@ -17,8 +17,15 @@ ;; i?86-*-solaris*) if test "$GCC" != yes ; then - need_tas=yes - tas_file=solaris_i386.s + soarch=`isainfo` + if isainfo | grep amd64 + then + need_tas=yes + tas_file=solaris_x86_64.s + else + need_tas=yes + tas_file=solaris_i386.s + fi fi ;; esac
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Import Notes
Reply to msg id not found: 43AC178E.6030508@gerad.ca | Resolved by subject fallback
Pierre Girard wrote:
Bruce Momjian wrote:
I have applied your patch with only minor comment additions. Let us
know if additional changes are required. Thanks.Are these flags required to be supplied to configure, or just the ASM
file?-Xa -xtarget=opteron -xarch=amd64
OK, I added this to the top of the ASM file as a comment.
If i remember right, the problem is that those options are passed to
configure but they're not set when compiling the asm file. Here's my
configure line since it appears it got lost somewhere.MAKE=gmake CC=/opt/SUNWspro/bin/cc CFLAGS="-xO3 -mt -fsimple=1
-ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt
-xtarget=opteron -xarch=amd64 -xregs=no%frameptr"
CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-xO3 -mt -fsimple=1 -ftrap=%none
-nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=opteron
-xarch=amd64 -xregs=no%frameptr" LDFLAGS="-xtarget=opteron -xarch=amd64"
./configure --without-readline
Wow, those are a lot of options. Are they all required? Are the
x64-specific?
---------------------------------------------------------------------------
I am thinking the port isn't 100% fool-proof yet, but it is _much_
closer than it was, and people can now do testing to improve it.---------------------------------------------------------------------------
Pierre Girard wrote:
Bruce Momjian wrote:
Interesting. Seems you have a setup that uses its own assembly source
file in port/tas/solaris_i386.s, rather than using inline C ASM. There
are files for both Sparc and i386 there, and are both used only for the
Sun compiler. Does the Sun compiler not support ASM inlining?I don't know but i imagine that if the postgresql team decided to do it
that way it's probably not supported.I also modified the function alignment from 4 to 8, patch
attached. Please give it a try and report back any error lines.I applied the patch and now the solaris_i386.s file compiles fine with
the command:
cc -Xa -xtarget=opteron -xarch=amd64 -c solaris_i386.sI made a few changes and was able to compile postgresql completely but i
don't think we'll be trying it until after the holidays. I included
the small changes i made but i'm sure you can make a much better job
than i did.Seems Sun might be interested in geting this working. We don't have an
official Sun contact yet for this project.Given this announcement, i'm surprised that you don't have a contact
already:
http://www.sun.com/smi/Press/sunflash/2005-11/sunflash.20051117.1.htmlHappy holidays everyone.
diff -Naur postgresql-8.1.1/src/Makefile.shlib postgresql-8.1.1.new/src/Makefile.shlib --- postgresql-8.1.1/src/Makefile.shlib Sat Dec 3 15:16:39 2005 +++ postgresql-8.1.1.new/src/Makefile.shlib Fri Dec 23 10:04:58 2005 @@ -193,7 +193,7 @@ ifeq ($(GCC), yes) LINK.shared = $(CC) -shared else - LINK.shared = $(CC) -G + LINK.shared = $(CC) -G $(CFLAGS) endif ifeq ($(with_gnu_ld), yes) LINK.shared += -Wl,-soname,$(soname) diff -Naur postgresql-8.1.1/src/backend/port/tas/solaris_x86_64.s postgresql-8.1.1.new/src/backend/port/tas/solaris_x86_64.s --- postgresql-8.1.1/src/backend/port/tas/solaris_x86_64.s Wed Dec 31 19:00:00 1969 +++ postgresql-8.1.1.new/src/backend/port/tas/solaris_x86_64.s Fri Dec 23 09:17:13 2005 @@ -0,0 +1,33 @@ +/============================================================================= +/ tas.s -- test and set lock for solaris_i386 +/============================================================================= + + .file "tas.s" + .text + .align 16 +.L1.text: + + .globl tas +tas: + pushq %rbp /save prev base pointer + movq %rsp,%rbp /new base pointer + pushq %rbx /save prev bx + movq 8(%rbp),%rbx /load bx with address of lock + movq $255,%rax /put something in ax + xchgb %al,(%rbx) /swap lock value with "0" + cmpb $0,%al /did we get the lock? + jne .Locked + subq %rax,%rax /yes, we got it -- return 0 + jmp .Finish + .align 8 +.Locked: + movq $1,%rax /no, we didn't get it - return 1 +.Finish: + popq %rbx /restore prev bx + movq %rbp,%rsp /restore stack state + popq %rbp + ret /return + .align 8 + .type tas,@function + .size tas,.-tas + diff -Naur postgresql-8.1.1/src/include/storage/s_lock.h postgresql-8.1.1.new/src/include/storage/s_lock.h --- postgresql-8.1.1/src/include/storage/s_lock.h Tue Oct 11 16:41:32 2005 +++ postgresql-8.1.1.new/src/include/storage/s_lock.h Fri Dec 23 09:18:44 2005 @@ -788,7 +788,7 @@/* out-of-line assembler from src/backend/port/tas/foo.s */
-#if defined(__sun) && defined(__i386) +#if defined(__sun) && (defined(__i386) || defined(__x86_64__)) /* * Solaris/386 (we only get here for non-gcc case) */ diff -Naur postgresql-8.1.1/src/template/solaris postgresql-8.1.1.new/src/template/solaris --- postgresql-8.1.1/src/template/solaris Fri Jul 29 13:00:29 2005 +++ postgresql-8.1.1.new/src/template/solaris Fri Dec 23 09:43:08 2005 @@ -17,8 +17,15 @@ ;; i?86-*-solaris*) if test "$GCC" != yes ; then - need_tas=yes - tas_file=solaris_i386.s + soarch=`isainfo` + if isainfo | grep amd64 + then + need_tas=yes + tas_file=solaris_x86_64.s + else + need_tas=yes + tas_file=solaris_i386.s + fi fi ;; esac
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Import Notes
Reply to msg id not found: 43BD3AB1.6070107@gerad.ca | Resolved by subject fallback
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Pierre Girard wrote:
MAKE=gmake CC=/opt/SUNWspro/bin/cc CFLAGS="-xO3 -mt -fsimple=1
-ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt
-xtarget=opteron -xarch=amd64 -xregs=no%frameptr"
CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-xO3 -mt -fsimple=1 -ftrap=%none
-nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=opteron
-xarch=amd64 -xregs=no%frameptr" LDFLAGS="-xtarget=opteron -xarch=amd64"
./configure --without-readline
Wow, those are a lot of options. Are they all required? Are the
x64-specific?
The CXX and CXXFLAGS settings are certainly entirely useless for PG.
regards, tom lane
Pierre Girard wrote:
Bruce Momjian wrote:
MAKE=gmake CC=/opt/SUNWspro/bin/cc CFLAGS="-xO3 -mt -fsimple=1
-ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt
-xtarget=opteron -xarch=amd64 -xregs=no%frameptr"
CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-xO3 -mt -fsimple=1 -ftrap=%none
-nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=opteron
-xarch=amd64 -xregs=no%frameptr" LDFLAGS="-xtarget=opteron -xarch=amd64"
./configure --without-readlineWow, those are a lot of options. Are they all required? Are the
x64-specific?They're definitely not all required, the ones needed to activate amd
specific code compilation are: -xtarget=opteron -xarch=amd64The other options were taken from a document from sun about optimizing
mysql on amd64 found at this address:
http://developers.sun.com/solaris/articles/mysql_perf_tune.html
I don't know if they would work on a different processor or not.Hopefully they'll make another document with postgresql in mind.
Thanks. I have added the URL.
---------------------------------------------------------------------------
I am thinking the port isn't 100% fool-proof yet, but it is _much_
closer than it was, and people can now do testing to improve it.---------------------------------------------------------------------------
Pierre Girard wrote:
Bruce Momjian wrote:
Interesting. Seems you have a setup that uses its own assembly source
file in port/tas/solaris_i386.s, rather than using inline C ASM. There
are files for both Sparc and i386 there, and are both used only for the
Sun compiler. Does the Sun compiler not support ASM inlining?I don't know but i imagine that if the postgresql team decided to do it
that way it's probably not supported.I also modified the function alignment from 4 to 8, patch
attached. Please give it a try and report back any error lines.I applied the patch and now the solaris_i386.s file compiles fine with
the command:
cc -Xa -xtarget=opteron -xarch=amd64 -c solaris_i386.sI made a few changes and was able to compile postgresql completely but i
don't think we'll be trying it until after the holidays. I included
the small changes i made but i'm sure you can make a much better job
than i did.Seems Sun might be interested in geting this working. We don't have an
official Sun contact yet for this project.Given this announcement, i'm surprised that you don't have a contact
already:
http://www.sun.com/smi/Press/sunflash/2005-11/sunflash.20051117.1.htmlHappy holidays everyone.
diff -Naur postgresql-8.1.1/src/Makefile.shlib postgresql-8.1.1.new/src/Makefile.shlib --- postgresql-8.1.1/src/Makefile.shlib Sat Dec 3 15:16:39 2005 +++ postgresql-8.1.1.new/src/Makefile.shlib Fri Dec 23 10:04:58 2005 @@ -193,7 +193,7 @@ ifeq ($(GCC), yes) LINK.shared = $(CC) -shared else - LINK.shared = $(CC) -G + LINK.shared = $(CC) -G $(CFLAGS) endif ifeq ($(with_gnu_ld), yes) LINK.shared += -Wl,-soname,$(soname) diff -Naur postgresql-8.1.1/src/backend/port/tas/solaris_x86_64.s postgresql-8.1.1.new/src/backend/port/tas/solaris_x86_64.s --- postgresql-8.1.1/src/backend/port/tas/solaris_x86_64.s Wed Dec 31 19:00:00 1969 +++ postgresql-8.1.1.new/src/backend/port/tas/solaris_x86_64.s Fri Dec 23 09:17:13 2005 @@ -0,0 +1,33 @@ +/============================================================================= +/ tas.s -- test and set lock for solaris_i386 +/============================================================================= + + .file "tas.s" + .text + .align 16 +.L1.text: + + .globl tas +tas: + pushq %rbp /save prev base pointer + movq %rsp,%rbp /new base pointer + pushq %rbx /save prev bx + movq 8(%rbp),%rbx /load bx with address of lock + movq $255,%rax /put something in ax + xchgb %al,(%rbx) /swap lock value with "0" + cmpb $0,%al /did we get the lock? + jne .Locked + subq %rax,%rax /yes, we got it -- return 0 + jmp .Finish + .align 8 +.Locked: + movq $1,%rax /no, we didn't get it - return 1 +.Finish: + popq %rbx /restore prev bx + movq %rbp,%rsp /restore stack state + popq %rbp + ret /return + .align 8 + .type tas,@function + .size tas,.-tas + diff -Naur postgresql-8.1.1/src/include/storage/s_lock.h postgresql-8.1.1.new/src/include/storage/s_lock.h --- postgresql-8.1.1/src/include/storage/s_lock.h Tue Oct 11 16:41:32 2005 +++ postgresql-8.1.1.new/src/include/storage/s_lock.h Fri Dec 23 09:18:44 2005 @@ -788,7 +788,7 @@/* out-of-line assembler from src/backend/port/tas/foo.s */
-#if defined(__sun) && defined(__i386) +#if defined(__sun) && (defined(__i386) || defined(__x86_64__)) /* * Solaris/386 (we only get here for non-gcc case) */ diff -Naur postgresql-8.1.1/src/template/solaris postgresql-8.1.1.new/src/template/solaris --- postgresql-8.1.1/src/template/solaris Fri Jul 29 13:00:29 2005 +++ postgresql-8.1.1.new/src/template/solaris Fri Dec 23 09:43:08 2005 @@ -17,8 +17,15 @@ ;; i?86-*-solaris*) if test "$GCC" != yes ; then - need_tas=yes - tas_file=solaris_i386.s + soarch=`isainfo` + if isainfo | grep amd64 + then + need_tas=yes + tas_file=solaris_x86_64.s + else + need_tas=yes + tas_file=solaris_i386.s + fi fi ;; esac
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Import Notes
Reply to msg id not found: 43BD3DF8.2080409@gerad.ca | Resolved by subject fallback