Обсуждение: 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.
Вложения
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.