Thread: Re: [PATCHES] HP-UX PA-RISC/Itanium 64-bit Patch and HP-UX 11.23 Patch
>> On Tue, 24 Aug 2004 00:39:55 -0400, Tom Lane <tgl@sss.pgh.pa.us> said: > Shinji Teragaito <shinji@kobe.hp.com> writes: >> I made a patch to let PostgreSQL work in the LP64 data model on >> HP-UX PA-RISC and HP-UX Itanium platform. > The s_lock change looks good ... but ... > This patch seems likely to break many other platforms. You do not > seriously expect us to apply that change to float8.out, do you? My patch is not related to the failure of the float8 test. Because you can see this failure when you compile the original cvs source code using GCC 3.4.1 on HP-UX 11.23 (Itanium) and run the regression test. Besides the failure of the float8 test, the create_function_1 and triggers tests fail. Please refer to the attached regression.diff. The result of float8.out diffs in this file are the same with the result I can see under the environment my patch is applied. The reason refint.sl has unresolved external symbol (__divdi3) is it's linked by /usr/ccs/bin/ld without libgcc.a. This is implemented in src/Makefile.port. Makefile.port in my patch use GCC to link refint.so. It results to link refint.so with libgcc.a implicitly and automatically. Anyway my patch will eliminate the failures of the create_function_1 and triggers test when GCC on HP-UX 11.23 will be used regardless of ILP32 or LP64. > I'd also like to know the rationale for the Makefile.shlib changes > (which did not seem to be needed the last time I tested on HPUX 11) Note I don't see this unresolved symbol problem when I use GCC 3.4.1 on HP-UX 11.11 (PA-RISC) even if my patch is not applied. I have not look into this deeply (I'm just wondering millicode routine on PA-RISC is related to this). Cheers, Shinji Teragaito Hewlett-Packard Japan, Ltd.
Attachment
Has this been resolved? --------------------------------------------------------------------------- Shinji Teragaito wrote: > >> On Tue, 24 Aug 2004 00:39:55 -0400, Tom Lane <tgl@sss.pgh.pa.us> said: > > > Shinji Teragaito <shinji@kobe.hp.com> writes: > >> I made a patch to let PostgreSQL work in the LP64 data model on > >> HP-UX PA-RISC and HP-UX Itanium platform. > > > The s_lock change looks good ... but ... > > > This patch seems likely to break many other platforms. You do not > > seriously expect us to apply that change to float8.out, do you? > > My patch is not related to the failure of the float8 test. Because > you can see this failure when you compile the original cvs source code > using GCC 3.4.1 on HP-UX 11.23 (Itanium) and run the regression test. > Besides the failure of the float8 test, the create_function_1 and > triggers tests fail. Please refer to the attached regression.diff. The > result of float8.out diffs in this file are the same with the result I > can see under the environment my patch is applied. > > The reason refint.sl has unresolved external symbol (__divdi3) is > it's linked by /usr/ccs/bin/ld without libgcc.a. This is implemented > in src/Makefile.port. Makefile.port in my patch use GCC to link > refint.so. It results to link refint.so with libgcc.a implicitly and > automatically. Anyway my patch will eliminate the failures of the > create_function_1 and triggers test when GCC on HP-UX 11.23 will be > used regardless of ILP32 or LP64. > > > I'd also like to know the rationale for the Makefile.shlib changes > > (which did not seem to be needed the last time I tested on HPUX 11) > > Note I don't see this unresolved symbol problem when I use GCC 3.4.1 > on HP-UX 11.11 (PA-RISC) even if my patch is not applied. I have not > look into this deeply (I'm just wondering millicode routine on PA-RISC > is related to this). > > Cheers, > > Shinji Teragaito > Hewlett-Packard Japan, Ltd. > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Has this been resolved?
AFAIK everything is fixed. I put in Shinji's changes and some more of
my own. I did port testing on HP 11.11 and 11.23 a month or so ago and
found that we could build and pass regression on both gcc and vendor
cc on both platforms.
regards, tom lane
>> On Thu, 07 Oct 2004 15:32:16 -0400, Tom Lane <tgl@sss.pgh.pa.us> said:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Has this been resolved?
> AFAIK everything is fixed. I put in Shinji's changes and some more of
> my own. I did port testing on HP 11.11 and 11.23 a month or so ago and
> found that we could build and pass regression on both gcc and vendor
> cc on both platforms.
As long as GNU ld is not installed and GNU gcc is used, the current
CVS head has two problems:
#1) ld: Mismatched Data ABI
In the LP64 data model, libpq.so creation fails because "-mlp64" is
missing in the back singlequote.
/usr/ccs/bin/ld +h libpq.so.3 -b +b /usr/local/pgsql/lib ..(snip)..
-L../../../src/port -lnsl `gcc -print-libgcc-file-name` -o
libpq.so.3
ld: Mismatched Data ABI. Expected EF_IA_64_ABI64 but found None in file
/usr/local/lib/gcc/ia64-hp-hpux11.23/3.4.1/libgcc.a[__divdi3.oS]
Fatal error.
#2) Two regresstion tests fail
create_function_1 and triggers tests fail because refint.so has
unresolved external symbol "__divdi3".
Cheers,
Shinji Teragaito
Hewlett-Packard Japan, Ltd.
Attachment
Shinji Teragaito <shinji@kobe.hp.com> writes:
152c152
< SHLIB_LINK += `$(CC) -print-libgcc-file-name`
---
> SHLIB_LINK += `$(CC) $(LDFLAGS) -print-libgcc-file-name`
Okay. I'm slightly worried about odd LDFLAGS values confusing this, but
we can deal with that when we see an example.
155c155
< LINK.shared = $(CC) $(LDFLAGS) -shared -Wl,-h -Wl,$(soname)
---
> LINK.shared = $(CC) $(LDFLAGS) -shared -Wl,-h -Wl,$(soname) -Wl,+b -Wl,$(libdir)
That looks good too. I think I had seen a truncated version of this
(just the +b part) and left it off because it didn't work.
I've applied both these changes.
58c58
< ifeq ($(with_gnu_ld), yes)
---
> ifeq ($(GCC), yes)
This I cannot apply; it breaks the gcc-with-HP-ld case, at least on my
personal installation (HPUX 10.20, gcc 2.95.3, HP ld). My tests on HP's
testdrive systems did not show any problem here --- what case are you
concerned about exactly?
regards, tom lane
>> On Fri, 08 Oct 2004 00:26:06 -0400, Tom Lane <tgl@sss.pgh.pa.us> said: > Shinji Teragaito <shinji@kobe.hp.com> writes: > 152c152 > < SHLIB_LINK += `$(CC) -print-libgcc-file-name` > --- >> SHLIB_LINK += `$(CC) $(LDFLAGS) -print-libgcc-file-name` > Okay. I'm slightly worried about odd LDFLAGS values confusing this, but > we can deal with that when we see an example. > 155c155 > < LINK.shared = $(CC) $(LDFLAGS) -shared -Wl,-h -Wl,$(soname) > --- >> LINK.shared = $(CC) $(LDFLAGS) -shared -Wl,-h -Wl,$(soname) -Wl,+b -Wl,$(libdir) > That looks good too. I think I had seen a truncated version of this > (just the +b part) and left it off because it didn't work. > I've applied both these changes. Thank you !! > 58c58 > < ifeq ($(with_gnu_ld), yes) > --- >> ifeq ($(GCC), yes) > This I cannot apply; it breaks the gcc-with-HP-ld case, at least on my > personal installation (HPUX 10.20, gcc 2.95.3, HP ld). My tests on HP's > testdrive systems did not show any problem here --- what case are you > concerned about exactly? gcc-with-HP-ld case on Itanium (HP-UX 11.23, gcc 3.4.1, HP ld). Cheers, Shinji Teragaito Hewlett-Packard Japan, Ltd.