Re: [PORTS] HP-UX port - Mailing list pgsql-ports
From | Tom Lane |
---|---|
Subject | Re: [PORTS] HP-UX port |
Date | |
Msg-id | 398.933260971@sss.pgh.pa.us Whole thread Raw |
In response to | Re: [PORTS] HP-UX port (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Responses |
Re: [PORTS] HP-UX port
|
List | pgsql-ports |
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > We should be shipping the postgres source tar files with flex/bison > already run on the parsing files. It sounds like at least one slipped > through the cracks. Tom, is this up your alley? It looks to me like he tried to build with the system yacc/lex. We already knew that HP's lex just Won't Work in HPUX 9 and 10 (doc/FAQ_HPUX points this out), and it seems HPUX 11 is no better. No big surprise though, since a lot of vendor lexes seem to fail. The compile failure in pl_gram.c looks to be a plain old portability mistake in src/pl/plpgsql/src/gram.y: it includes pl_scan.c in the grammar header section, which works OK in bison output because bison emits the #define constants before copying the header. I expect that HP's yacc does it in some other order. Jan, may I suggest moving the #include "pl_scan.c" down to the file trailer? Or compiling the lexer as a separate source file, like everyone else does? > I changed in configure.guess the following: > # diff config.guess.orig config.guess > 371c371 > < 9000/6?? | 9000/7?? | 9000/80[24] | 9000/8?[13679] | > 9000/892 ) > --- > > 9000/6?? | 9000/7?? | 9000/80[024] | 9000/8?[13679] | > > 9000/892 ) I wonder why the GNU guys aren't just using 9000/8?? ... actually they might be by now. I think our copy of config.guess is already a few revisions out of date. > I ran the regression tests and the bench tests (WISC). Some > regression tests failed, but that is to be expected I supposed. The "failures" enumerated in FAQ_HPUX are to be expected. Did you see any others? (I can send you a copy of what I consider the normal regression diffs on HPUX 9/10; it'd be interesting to see if 11 is any different...) > However, when I ran the bench tests. only queries 1-15 run. After that, > postgresql dies with a FATAL error due to a stuck spinlock: > > FATAL: s_lock(400c122c) at bufmgr.c:665, stuck spinlock. Aborting. > > If anyone wants more information on this bug let me know and I will see > what I can do :). This appears to be worth digging into. I've been running Postgres for quite some time on HPUX 9 and 10 and not seen any such problem. BTW, are you building in a 32- or 64-bit environment? We are gradually flushing 64-bit-long portability bugs out of the code, but I am sure some remain. Check the pgsql mailing list archives for discussions mentioning Alpha platforms to see what's been found before. regards, tom lane
pgsql-ports by date: