Thread: Re: [HACKERS] HP-UX PA-RISC/Itanium 64-bit Patch and HP-UX
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.