Thread: Call for platforms
Results of 'make check':
NetBSD-1.5/i386 one spurious floating point test failure (mail sent to postgresql-bugs with details)
NetBSD_1.5/alpha all tests passed
NetBSD-1.4.2/i386 four tests fail timestamp ... FAILED abstime ... FAILED
tinterval ... FAILED test horology ... FAILED
I'll look into the 1.4.2 failures when/if I get time. If anyone wants
the test output to examine please ask.
Regards,
Giles
> NetBSD-1.5/i386 one spurious floating point test failure
> (mail sent to postgresql-bugs with details)
> NetBSD_1.5/alpha all tests passed
> NetBSD-1.4.2/i386 four tests fail
Thanks! I'm not too worried about 1.4.2, but be sure to let us know what
the problem was; it may help out someone else...
- Thomas
> > OpenBSD 2.8 x86 7.1 2001-03-22, B. Palmer (first name?)
> Though it does work, like FBSD, there are some changes that need to be
> made to the system. Need max proc / files changes and a kernel recompile
> with SEMMNI and SEMMNS changes. Anywhere special to note this?
So more-or-less the *same* configuration as is required for FBSD? If so,
I could note that in the comments part of the platform support table.
I'm not sure if either one (OBSD, FBSD) is actually explicitly
documented for PostgreSQL (I don't see a FAQ, and am not sure if there
is something in the sgml docs). Does anyone know if and where these
things are noted?
- Thomas
On Thu, 22 Mar 2001, Thomas Lockhart wrote: > > > OpenBSD 2.8 x86 7.1 2001-03-22, B. Palmer (first name?) > > Though it does work, like FBSD, there are some changes that need to be > > made to the system. Need max proc / files changes and a kernel recompile > > with SEMMNI and SEMMNS changes. Anywhere special to note this? > > So more-or-less the *same* configuration as is required for FBSD? If so, > I could note that in the comments part of the platform support table. The kernel changes are the same, but OBSD needs the max proc, max open file settings changes (no reboot required). > > I'm not sure if either one (OBSD, FBSD) is actually explicitly > documented for PostgreSQL (I don't see a FAQ, and am not sure if there > is something in the sgml docs). Does anyone know if and where these > things are noted? http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.html This is the closest thing to docs. kernel-resources for specific OSs. - b b. palmer, bpalmer@crimelabs.net pgp: www.crimelabs.net/bpalmer.pgp5
Thomas Lockhart writes: > > > OpenBSD 2.8 x86 7.1 2001-03-22, B. Palmer (first name?) > > Though it does work, like FBSD, there are some changes that need to be > > made to the system. Need max proc / files changes and a kernel recompile > > with SEMMNI and SEMMNS changes. Anywhere special to note this? > > So more-or-less the *same* configuration as is required for FBSD? If so, > I could note that in the comments part of the platform support table. Quite a few platforms will need some tuning in that area before production use. This is all documented. > I'm not sure if either one (OBSD, FBSD) is actually explicitly > documented for PostgreSQL (I don't see a FAQ, and am not sure if there > is something in the sgml docs). Does anyone know if and where these > things are noted? > > - Thomas > -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> > NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean
> Correction: NetBSD-1.5/alpha.
Right. That was a typo in transcribing my online copy of the sgml docs
to the email. I was hoping no one caught it, and didn't bother sending a
correction ;)
- Thomas
> Seems that following patch is needed. Now It Works For Me (tm). > Giles, does the regress test now succed for you? Yes, but I don't like that it is 1.5 specific. I expect that later NetBSD/i386 releases will also have the "new" floating point behaviour by default, subject to /etc/ld.so.conf setting as Patrick Welche discovered. BTW NetBSD just uses "i386" for any x86. It's not necessary to allow for i486, i586 etc. Perhaps the resultmap format could be enhanced to allow wildcarding of the result files, and just accept either match? geometry/.*-netbsd=geometry-positive-zeros* Regards, Giles > Index: src/test/regress/resultmap > =================================================================== > RCS file: /home/projects/pgsql/cvsroot/pgsql/src/test/regress/resultmap,v > retrieving revision 1.45 > diff -u -r1.45 resultmap > --- src/test/regress/resultmap 2001/03/22 15:13:18 1.45 > +++ src/test/regress/resultmap 2001/03/22 17:29:49 > @@ -17,6 +17,7 @@ > geometry/.*-openbsd=geometry-positive-zeros-bsd > geometry/.*-irix6=geometry-irix > geometry/.*-netbsd=geometry-positive-zeros > +geometry/i.86-.*-netbsdelf1.5=geometry-positive-zeros-bsd > geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc > geometry/.*-sysv5uw7.*:gcc=geometry-uw7-gcc > geometry/alpha.*-dec-osf=geometry-alpha-precision
"Mark Knox" <segfault@hardline.org> writes:
> On 25 Mar 2001, at 16:07, Tom Lane wrote:
>> Does that database have any user-created relations in it, or is it
>> just a virgin database?
> Totally virgin. I created it just for that select you wanted.
Okay. Would you create a couple of random tables in it and do the
select again? I want to see what ctid looks like in a user-created
table.
> I suspect it might be an alignment problem
Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8
rather than 6 as one might expect.
regards, tom lane
I've already reported this to the webpage, but I got a fail on the random
test:
random ... failed (ignored)
This is on a stock RedHat 7.0 kernel box with the SMP kernel (but running a
single processor):
[pjm3@localhost regress]$ less regression.diffs
*** ./expected/random.out Thu Jan 6 06:40:54 2000
--- ./results/random.out Tue Mar 27 15:07:16 2001
***************
*** 25,31 **** GROUP BY random HAVING count(random) > 1; random | count --------+-------
! (0 rows)
SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120;
--- 25,32 ---- GROUP BY random HAVING count(random) > 1; random | count --------+-------
! 99 | 2
! (1 row)
SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120;
======================================================================
Regards,
Phil
+----------------------------------+
| Phil Mayers, Network Support |
| Centre for Computing Services |
| Imperial College |
+----------------------------------+
"Mayers, Philip J" <p.mayers@ic.ac.uk> writes: > I've already reported this to the webpage, but I got a fail on the random > test: > random ... failed (ignored) See http://www.postgresql.org/devel-corner/docs/postgres/regress.html especially the last item ... regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- On 26 Mar 2001, at 23:14, Tom Lane wrote: > "Mark Knox" <segfault@hardline.org> writes: > > On 25 Mar 2001, at 16:07, Tom Lane wrote: > >> Does that database have any user-created relations in it, or is it > >> just a virgin database? > > > Totally virgin. I created it just for that select you wanted. > > Okay. Would you create a couple of random tables in it and do the > select again? I want to see what ctid looks like in a user-created > table. Sure. I created two tables called 'test1' and 'test2'. Test1 has a single field 'field1' of type int4. Test2 has two fields 'field1' and 'field2' of types char(200) and int4 respectively. Here are the results: postgres=> select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; oid|attrelid|relname |attname|attlen|attalign|attbyval - -----+--------+--------------+-------+------+--------+-------- 16401| 1247|pg_type |ctid | 6|i |f 16415| 1262|pg_database |ctid | 6|i |f 16439| 1255|pg_proc |ctid | 6|i |f 16454| 1260|pg_shadow |ctid | 6|i |f 16464| 1261|pg_group |ctid | 6|i |f 16486| 1249|pg_attribute |ctid | 6|i |f 16515| 1259|pg_class |ctid | 6|i |f 16526| 1215|pg_attrdef |ctid | 6|i |f 16537| 1216|pg_relcheck |ctid | 6|i |f 16557| 1219|pg_trigger |ctid | 6|i |f 16572| 16567|pg_inherits |ctid | 8|i |f 16593| 16579|pg_index |ctid | 8|i |f 16610| 16600|pg_statistic |ctid | 8|i |f 16635| 16617|pg_operator |ctid | 8|i |f 16646| 16642|pg_opclass |ctid | 8|i |f 16678| 16653|pg_am |ctid | 8|i |f 16691| 16685|pg_amop |ctid | 8|i |f 16873| 16867|pg_amproc |ctid | 8|i |f 16941| 16934|pg_language |ctid | 8|i |f 16953| 16948|pg_largeobject|ctid | 8|i |f 16970| 16960|pg_aggregate |ctid | 8|i |f 17038| 17033|pg_ipl |ctid | 8|i |f 17051| 17045|pg_inheritproc|ctid | 8|i |f 17067| 17058|pg_rewrite |ctid | 8|i |f 17079| 17074|pg_listener |ctid | 8|i |f 17090| 17086|pg_description|ctid | 8|i |f 17206| 17201|pg_toast_1215 |ctid | 8|i |f 17221| 17216|pg_toast_17086|ctid | 8|i |f 17236| 17231|pg_toast_1255 |ctid | 8|i |f 17251| 17246|pg_toast_1216 |ctid | 8|i |f 17266| 17261|pg_toast_17058|ctid | 8|i |f 17281| 17276|pg_toast_16600|ctid | 8|i |f 17301| 17291|pg_user |ctid | 8|i |f 17314| 17309|pg_rules |ctid | 8|i |f 17327| 17322|pg_views |ctid | 8|i |f 17342| 17335|pg_tables |ctid | 8|i |f 17355| 17350|pg_indexes |ctid | 8|i |f 18724| 18721|test1 |ctid | 8|i |f 18735| 18731|test2 |ctid | 8|i |f (39 rows) > > I suspect it might be an alignment problem > > Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8 > rather than 6 as one might expect. Maybe it's padding the structure to a dword boundary? ARM is notorious for such things.. I will rebuild it with __attribute__((packed)) on the struct and see if the size changes.. -----BEGIN PGP SIGNATURE----- Version: N/A iQCVAwUBOsFDJP+IdJuhyV9xAQEKxQP/YJXTxZppLd7ECk4BSwDZaStP4+bE6acc StT//i/drdPC53DDWqiXLGA0bS384EXxyjvvaO1bTXzVFU/3+X/pY6YN/G3HMoah dbCXRli2Y57yansf1WaVmK1lhiAqLy3iGYFp2nZvO1Sl1u+ba89HtV+G+iaKZSTr U+HWTU3nnOM= =vkY+ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- On 27 Mar 2001, at 20:49, Mark Knox wrote: > > > I suspect it might be an alignment problem > > > > Sort of. I am suspicious that sizeof(ItemPointerData) is returning > > 8 rather than 6 as one might expect. > > Maybe it's padding the structure to a dword boundary? ARM is > notorious for such things.. I will rebuild it with > __attribute__((packed)) on the struct and see if the size changes.. Aha, progress! The packed directive gives attlen of 6 across the board! Type_sanity test passes now too, so the only failing regression test is geometry and that is easily dismissed. The variation is in the last decimal place and probably due to emulated floating point (ARM has no FPU). The patch is attached.. it's tiny but seems to be effective. -----BEGIN PGP SIGNATURE----- Version: N/A iQCVAwUBOsFeUv+IdJuhyV9xAQE2XAP9FF93ew+6Ml5iZ1jWjcGrs+3zaXIeWef6 SytNtIfyJqmcnyWnMaxBTlChIvBO5A2HVnBkCydM5BjUXdW1eWsEynrd+U79Yc+e yVDGo30CK3lAkTLH3Fo6jR3YZe/TsIyr80WlDeqJiWvDmHTfqvo50jRiDq2h1OL/ LmI4YIQM0rQ= =Vwwp -----END PGP SIGNATURE-----
The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: arm-alignment.patch Date: 27 Mar 2001, 21:26 Size: 533 bytes. Type: Unknown
"Mark Knox" <segfault@hardline.org> writes:
> {
> BlockIdData ip_blkid;
> OffsetNumber ip_posid;
> +#ifdef __arm__
> +} __attribute__((packed)) ItemPointerData;
> +#else
> }
> +#endif
That would fix it for ARM but not for anyplace else with similar
alignment behavior. Would you try this patch instead to see what
happens?
regards, tom lane
*** src/backend/catalog/heap.c.orig Thu Mar 22 09:50:36 2001
--- src/backend/catalog/heap.c Wed Mar 28 00:24:45 2001
***************
*** 103,109 **** */ static FormData_pg_attribute a1 = {
! 0xffffffff, {"ctid"}, TIDOID, 0, sizeof(ItemPointerData), SelfItemPointerAttributeNumber, 0, -1, -1, '\0',
'p','\0', 'i', '\0', '\0' };
--- 103,109 ---- */ static FormData_pg_attribute a1 = {
! 0xffffffff, {"ctid"}, TIDOID, 0, SizeOfIptrData, SelfItemPointerAttributeNumber, 0, -1, -1, '\0', 'p', '\0',
'i','\0', '\0' };
At 12:27 AM 3/28/01 -0500, Tom Lane wrote:
>That would fix it for ARM but not for anyplace else with similar
>alignment behavior. Would you try this patch instead to see what
>happens?
I don't think this solution would be valid on many other platforms. It forces the structure to not be padded, and
assumesthat the cpu will be able to fetch from unaligned boundaries. The only reason this works is that the arm linux
kernelcontains an alignment trap handler that catches the fault and does a fixup on the access. Otherwise it would
crashwith SIGBUS.
> static FormData_pg_attribute a1 = {
>! 0xffffffff, {"ctid"}, TIDOID, 0, SizeOfIptrData,
> SelfItemPointerAttributeNumber, 0, -1, -1, '\0', 'p', '\0', 'i', '\0', '\0'
> };
Well, this patch seems to produce attlens of 6 as desired, but it causes many (13) of the regression tests to fail. Do
youwant to see the regression.diffs?
Mark Knox <segfault@hardline.org> writes:
> I don't think this solution would be valid on many other platforms.
Au contraire --- the ARM is the first platform I've heard of that does
not think sizeof(ItemPointerData) is 6. Else we'd have seen this
regress test fail before.
> Well, this patch seems to produce attlens of 6 as desired, but it
> causes many (13) of the regression tests to fail. Do you want to see
> the regression.diffs?
Please.
regards, tom lane
Mark Knox <segfault@hardline.org> writes:
> Well, this patch seems to produce attlens of 6 as desired, but it
> causes many (13) of the regression tests to fail. Do you want to see
> the regression.diffs?
>>
>> Please.
> See attached.
Does look pretty broken, but I don't see how my idea would have led to
all this other stuff failing. Anyway, I guess the path of least
resistance is to install your ARM-specific packing patch. It's
important to make sure that sizeof(ItemPointerData) is 6 if at all
possible, since it will cost you four or so wasted bytes in every
tuple header if it's not. Will take care of it for RC2.
regards, tom lane
At 11:06 PM 3/28/01 -0500, Tom Lane wrote: >Mark Knox <segfault@hardline.org> writes: >> I don't think this solution would be valid on many other platforms. > >Au contraire --- the ARM is the first platform I've heard of that does >not think sizeof(ItemPointerData) is 6. Else we'd have seen this >regress test fail before. I meant I don't think *my* solution (ie packing the struct) would be valid anywhere else. It seems to be an arm-specificproblem so maybe it needs an arm-specific patch? I've had to do this type of thing many times to get packagesworking properly in arm linux. It's a quirky platform. >> Well, this patch seems to produce attlens of 6 as desired, but it >> causes many (13) of the regression tests to fail. Do you want to see >> the regression.diffs? > >Please. See attached.
Attachment
Bottom line: 7.1RC1 passes most of the regression tests on NetBSD/macppc. It's probably good enough for normal use since the differences are not extensive, but someone would need to look at the diff's for longer than the 10 seconds or so I've spent so far, and someone should actually set it up for real use to check that. I used the vanilla tarball from postgresql.org, not the NetBSD package system. Details: It's clearly less clean than the OS X build. Also my G4 desktop runs rings around both a Sun Ultra 1 and the 8500 I have NetBSD on for stuff like this build. I'm actually reevaluating how much I want to keep running real open source OS's vs the partly open MacOS X when both the OS and this application runs so much cleaner on the most recent (fastest) hardware. I like Apple stuff, but I never thought I would be this impressed with OS X this quickly. I guess I should shut up now or risk a flame war since the point is the PG port quality and not how good the target platform is. >% gmake check >gmake -C ../../../contrib/spi REFINT_VERBOSE=1 refint.so autoinc.so >gmake[1]: Entering directory `/usr/local/dist/postgresql-7.1RC1/contrib/spi' >gmake[1]: `refint.so' is up to date. >gmake[1]: `autoinc.so' is up to date. >gmake[1]: Leaving directory `/usr/local/dist/postgresql-7.1RC1/contrib/spi' >/bin/sh ./pg_regress --temp-install --top-builddir=../../.. >--schedule=./parallel_schedule --multibyte= >============== removing existing temp installation ============== >============== creating temporary installation ============== >============== initializing database system ============== >============== starting postmaster ============== >running on port 65432 with pid 21643 >============== creating database "regression" ============== >CREATE DATABASE >============== installing PL/pgSQL ============== >============== running regression test queries ============== >parallel group (13 tests): text float4 varchar oid int2 char >boolean int4 int8 name float8 bit numeric > boolean ... ok > char ... ok > name ... ok > varchar ... ok > text ... ok > int2 ... ok > int4 ... ok > int8 ... ok > oid ... ok > float4 ... ok > float8 ... ok > bit ... ok > numeric ... ok >test strings ... ok >test numerology ... ok >parallel group (18 tests): path interval date time circle reltime >box lseg abstime inet point comments tinterval polygon timestamp >type_sanity oidjoins opr_sanity > point ... ok > lseg ... ok > box ... ok > path ... ok > polygon ... ok > circle ... ok > date ... ok > time ... ok > timestamp ... ok > interval ... ok > abstime ... ok > reltime ... ok > tinterval ... ok > inet ... ok > comments ... ok > oidjoins ... ok > type_sanity ... ok > opr_sanity ... ok >test geometry ... FAILED >test horology ... FAILED >test create_function_1 ... ok >test create_type ... ok >test create_table ... ok >test create_function_2 ... ok >test copy ... ok >parallel group (7 tests): create_operator create_aggregate inherit >triggers constraints create_misc create_index > constraints ... ok > triggers ... ok > create_misc ... ok > create_aggregate ... ok > create_operator ... ok > create_index ... ok > inherit ... ok >test create_view ... ok >test sanity_check ... ok >test errors ... ok >test select ... ok >parallel group (16 tests): arrays select_having select_distinct >transactions random portals select_into union select_distinct_on >select_implicit case subselect aggregates btree_index join hash_index > select_into ... ok > select_distinct ... ok > select_distinct_on ... ok > select_implicit ... ok > select_having ... ok > subselect ... ok > union ... ok > case ... ok > join ... ok > aggregates ... ok > transactions ... ok > random ... ok > portals ... ok > arrays ... ok > btree_index ... ok > hash_index ... ok >test misc ... ok >parallel group (5 tests): portals_p2 alter_table foreign_key >select_views rules > select_views ... ok > alter_table ... ok > portals_p2 ... ok > rules ... ok > foreign_key ... ok >parallel group (3 tests): temp limit plpgsql > limit ... ok > plpgsql ... ok > temp ... ok >============== shutting down postmaster ============== > >======================= > 2 of 76 tests failed. >======================= > >The differences that caused some tests to fail can be viewed in the >file `./regression.diffs'. A copy of the test summary that you see >above is saved in the file `./regression.out'. The diff is: >*** ./expected/geometry-positive-zeros.out Tue Sep 12 14:07:16 2000 >--- ./results/geometry.out Thu Apr 5 08:29:58 2001 >*************** >*** 445,451 **** > >-----+---------------------------------------------------------------- >---------------------------------------------------------------------- >---------------------------------------------------------------------- >---------------------------------------------------------------------- >---------------------------------------------------------------------- >------------------------------------- > | >((-3,0),(-2.59807621135076,1.50000000000442),(-1.49999999999116,2.5980 >7621135842),(1.53102359017709e-11,3),(1.50000000001768,2.5980762113431 >1),(2.59807621136607,1.4999999999779),(3,-3.06204718035418e-11),(2.598 >07621133545,-1.50000000003094),(1.49999999996464,-2.59807621137373),(- >4.59307077053127e-11,-3),(-1.5000000000442,-2.5980762113278),(-2.59807 >621138138,-1.49999999995138)) > | >((-99,2),(-85.6025403783588,52.0000000001473),(-48.9999999997054,88.60 >2540378614),(1.00000000051034,102),(51.0000000005893,88.6025403781036) >,(87.6025403788692,51.9999999992634),(101,1.99999999897932),(87.602540 >3778485,-48.0000000010313),(50.9999999988214,-84.6025403791243),(0.999 >999998468976,-98),(-49.0000000014732,-84.6025403775933),(-85.602540379 >3795,-47.9999999983795)) >! | >((-4,3),(-3.33012701891794,5.50000000000737),(-1.49999999998527,7.3301 >270189307),(1.00000000002552,8),(3.50000000002946,7.33012701890518),(5 >.33012701894346,5.49999999996317),(6,2.99999999994897),(5.330127018892 >42,0.499999999948437),(3.49999999994107,-1.33012701895622),(0.99999999 >9923449,-2),(-1.50000000007366,-1.33012701887967),(-3.33012701896897,0 >.500000000081028)) > | >((-2,2),(-1.59807621135076,3.50000000000442),(-0.499999999991161,4.598 >07621135842),(1.00000000001531,5),(2.50000000001768,4.59807621134311), >(3.59807621136607,3.4999999999779),(4,1.99999999996938),(3.59807621133 >545,0.499999999969062),(2.49999999996464,-0.598076211373729),(0.999999 >999954069,-1),(-0.500000000044197,-0.598076211327799),(-1.598076211381 >38,0.500000000048616)) > | >((90,200),(91.3397459621641,205.000000000015),(95.0000000000295,208.66 >0254037861),(100.000000000051,210),(105.000000000059,208.66025403781), >(108.660254037887,204.999999999926),(110,199.999999999898),(108.660254 >037785,194.999999999897),(104.999999999882,191.339745962088),(99.99999 >99998469,190),(94.9999999998527,191.339745962241),(91.3397459620621,19 >5.000000000162)) > | >((0,0),(13.3974596216412,50.0000000001473),(50.0000000002946,86.602540 >378614),(100.00000000051,100),(150.000000000589,86.6025403781036),(186 >.602540378869,49.9999999992634),(200,-1.02068239345139e-09),(186.60254 >0377848,-50.0000000010313),(149.999999998821,-86.6025403791243),(99.99 >9999998469,-100),(49.9999999985268,-86.6025403775933),(13.397459620620 >5,-49.9999999983795)) >--- 445,451 ---- > >-----+---------------------------------------------------------------- >---------------------------------------------------------------------- >---------------------------------------------------------------------- >---------------------------------------------------------------------- >---------------------------------------------------------------------- >------------------------------------- > | >((-3,0),(-2.59807621135076,1.50000000000442),(-1.49999999999116,2.5980 >7621135842),(1.53102359017709e-11,3),(1.50000000001768,2.5980762113431 >1),(2.59807621136607,1.4999999999779),(3,-3.06204718035418e-11),(2.598 >07621133545,-1.50000000003094),(1.49999999996464,-2.59807621137373),(- >4.59307077053127e-11,-3),(-1.5000000000442,-2.5980762113278),(-2.59807 >621138138,-1.49999999995138)) > | >((-99,2),(-85.6025403783588,52.0000000001473),(-48.9999999997054,88.60 >2540378614),(1.00000000051034,102),(51.0000000005893,88.6025403781036) >,(87.6025403788692,51.9999999992634),(101,1.99999999897932),(87.602540 >3778485,-48.0000000010313),(50.9999999988214,-84.6025403791243),(0.999 >999998468976,-98),(-49.0000000014732,-84.6025403775933),(-85.602540379 >3795,-47.9999999983795)) >! | >((-4,3),(-3.33012701891794,5.50000000000737),(-1.49999999998527,7.3301 >270189307),(1.00000000002552,8),(3.50000000002946,7.33012701890518),(5 >.33012701894346,5.49999999996317),(6,2.99999999994897),(5.330127018892 >42,0.499999999948437),(3.49999999994107,-1.33012701895622),(0.99999999 >9923449,-2),(-1.50000000007366,-1.33012701887966),(-3.33012701896897,0 >.500000000081027)) > | >((-2,2),(-1.59807621135076,3.50000000000442),(-0.499999999991161,4.598 >07621135842),(1.00000000001531,5),(2.50000000001768,4.59807621134311), >(3.59807621136607,3.4999999999779),(4,1.99999999996938),(3.59807621133 >545,0.499999999969062),(2.49999999996464,-0.598076211373729),(0.999999 >999954069,-1),(-0.500000000044197,-0.598076211327799),(-1.598076211381 >38,0.500000000048616)) > | >((90,200),(91.3397459621641,205.000000000015),(95.0000000000295,208.66 >0254037861),(100.000000000051,210),(105.000000000059,208.66025403781), >(108.660254037887,204.999999999926),(110,199.999999999898),(108.660254 >037785,194.999999999897),(104.999999999882,191.339745962088),(99.99999 >99998469,190),(94.9999999998527,191.339745962241),(91.3397459620621,19 >5.000000000162)) > | >((0,0),(13.3974596216412,50.0000000001473),(50.0000000002946,86.602540 >378614),(100.00000000051,100),(150.000000000589,86.6025403781036),(186 >.602540378869,49.9999999992634),(200,-1.02068239345139e-09),(186.60254 >0377848,-50.0000000010313),(149.999999998821,-86.6025403791243),(99.99 >9999998469,-100),(49.9999999985268,-86.6025403775933),(13.397459620620 >5,-49.9999999983795)) > >====================================================================== > >*** ./expected/horology.out Sun Dec 3 06:51:11 2000 >--- ./results/horology.out Thu Apr 5 08:30:01 2001 >*************** >*** 122,128 **** > SELECT time with time zone '01:30' + interval '02:01' AS "03:31:00-08"; > 03:31:00-08 > ------------- >! 03:31:00-08 > (1 row) > > SELECT time with time zone '01:30-08' - interval '02:01' AS "23:29:00-08"; >--- 122,128 ---- > SELECT time with time zone '01:30' + interval '02:01' AS "03:31:00-08"; > 03:31:00-08 > ------------- >! 03:31:00-07 > (1 row) > > SELECT time with time zone '01:30-08' - interval '02:01' AS "23:29:00-08"; >*************** >*** 140,146 **** > SELECT time with time zone '03:30' + interval '1 month 04:01' AS >"07:31:00-08"; > 07:31:00-08 > ------------- >! 07:31:00-08 > (1 row) > > SELECT interval '04:30' - time with time zone '01:02' AS "+03:28"; >--- 140,146 ---- > SELECT time with time zone '03:30' + interval '1 month 04:01' AS >"07:31:00-08"; > 07:31:00-08 > ------------- >! 07:31:00-07 > (1 row) > > SELECT interval '04:30' - time with time zone '01:02' AS "+03:28"; > >====================================================================== > During the build I got these ugly, but presumably harmless complaints: >gmake[4]: Entering directory >`/usr/local/dist/postgresql-7.1RC1/src/pl/plpgsql/src' >gcc -c -I. -I../../../../src/include -O2 -pipe -Wall >-Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -o >pl_parse.o pl_gram.c >lex.plpgsql_yy.c: In function `plpgsql_yylex': >lex.plpgsql_yy.c:971: warning: label `find_rule' defined but not used >lex.plpgsql_yy.c: At top level: >lex.plpgsql_yy.c:2223: warning: `plpgsql_yy_flex_realloc' defined but not used in a few places, and >gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations >-I../../../src/interfaces/libpq -I../../../src/include -c -o >tab-complete.o tab-complete.c >tab-complete.c: In function `initialize_readline': >tab-complete.c:103: warning: assignment from incompatible pointer type >tab-complete.c: In function `psql_completion': >tab-complete.c:292: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:296: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:301: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:309: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:320: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:325: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:332: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:337: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:342: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:347: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:350: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:366: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:371: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:378: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:381: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:392: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:400: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:406: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:410: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:413: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:420: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:423: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:429: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:435: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:440: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:448: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:455: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:460: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:465: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:473: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:478: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:490: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:493: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:496: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:506: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:514: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:521: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:532: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:541: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:545: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:553: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:556: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:559: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:569: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:572: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:578: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:582: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:587: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:592: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:599: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:604: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:606: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:608: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:619: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:622: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:626: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:634: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:640: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:646: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:651: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:660: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:666: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:672: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:678: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:682: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:687: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:690: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:698: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:702: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:704: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:709: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:714: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:716: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:718: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:725: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:749: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >tab-complete.c:763: warning: passing arg 2 of `completion_matches' >from incompatible pointer type >gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations >command.o common.o help.o input.o stringutils.o mainloop.o copy.o >startup.o prompt.o variables.o large_obj.o print.o describe.o >tab-complete.o -L../../../src/interfaces/libpq -lpq >-Wl,-R/usr/local/lib -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit >-ltermcap -o psql >gmake[3]: Leaving directory `/usr/local/dist/postgresql-7.1RC1/src/bin/psql' Great work as always. It's been nice to see the progressive improvement in the portability and quality of the DBMS over the years. Signature held pending an ISO 9000 compliant signature design and approval process. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
> Bottom line: 7.1RC1 passes most of the regression tests on
> NetBSD/macppc. It's probably good enough for normal use since the
> differences are not extensive, but someone would need to look at the
> diff's for longer than the 10 seconds or so I've spent so far, and
> someone should actually set it up for real use to check that.
I'll mark it as supported; the horology diffs are not significant and
geometry is known to be a bit different on some platforms.
Including the not-tested-for-7.1 NetBSD/m68k, we are supported on 30
platforms for the upcoming release, with definite potential for a couple
of more (QNX and Ultrix).
*That* is some sort of milestone! :))
- Thomas
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
> Bottom line: 7.1RC1 passes most of the regression tests on
> NetBSD/macppc.
The only thing that surprised me here was all of the warnings from
libreadline calls:
>> tab-complete.c: In function `initialize_readline':
>> tab-complete.c:103: warning: assignment from incompatible pointer type
>> tab-complete.c: In function `psql_completion':
>> tab-complete.c:292: warning: passing arg 2 of `completion_matches'
>> from incompatible pointer type
>> tab-complete.c:296: warning: passing arg 2 of `completion_matches'
>> from incompatible pointer type
What version of libreadline do you have installed, and how does it
declare completion_matches()?
regards, tom lane
If somethings happen this weekend, I *MAY* have a HP9000/433s (M68K) running NetBSD to play with.... Not enough to hold up the release, but... LER >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 4/6/01, 12:29:28 AM, Thomas Lockhart <lockhart@alumni.caltech.edu> wrote regarding [HACKERS] Re: Call for platforms: > > Bottom line: 7.1RC1 passes most of the regression tests on > > NetBSD/macppc. It's probably good enough for normal use since the > > differences are not extensive, but someone would need to look at the > > diff's for longer than the 10 seconds or so I've spent so far, and > > someone should actually set it up for real use to check that. > I'll mark it as supported; the horology diffs are not significant and > geometry is known to be a bit different on some platforms. > Including the not-tested-for-7.1 NetBSD/m68k, we are supported on 30 > platforms for the upcoming release, with definite potential for a couple > of more (QNX and Ultrix). > *That* is some sort of milestone! :)) > - Thomas > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > http://www.postgresql.org/users-lounge/docs/faq.html
> If somethings happen this weekend, I *MAY* have a HP9000/433s (M68K)
> running NetBSD to play with....
That would be great. I *know* that there are some m68k machines around
somewhere on this planet, and it would be a shame to not have NetBSD
tested for the release...
- Thomas
> Thanks! I'm not too worried about 1.4.2, but be sure to let us know what > the problem was; it may help out someone else... NetBSD-1.4.2/i386 passes all tests with 7.1RC3. My previous test failure on this platform was due to the timezone information on the test system not being standard; once that was corrected all tests pass. It is still necessary to add -ltermcap after -ledit in src/Makefile.global to have functional history editing in psql. Regards, Giles
Giles Lean <giles@nemeton.com.au> writes: > It is still necessary to add -ltermcap after -ledit in > src/Makefile.global to have functional history editing in psql. This is a weakness in the configure script: it goes through a loop where it tries to link a program that calls readline() with, in order, "-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses", "-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit -lncurses" and "-ledit -lcurses". The first link that succeeds wil determine which libraries are used. However, on some platforms with dynamic libraries, the link will succeed as soon as readline() is present -- but the shared library that contains it doesn't contain a complete specification of all other libraries it needs at run-time (the executable is expected to hold this information), and the program fails at run-time even though it linked without any error message. I don't know how the situation could best be improved, though... -tih -- The basic difference is this: hackers build things, crackers break them.
Tom Ivar Helbekkmo writes: > Giles Lean <giles@nemeton.com.au> writes: > > > It is still necessary to add -ltermcap after -ledit in > > src/Makefile.global to have functional history editing in psql. > > This is a weakness in the configure script: it goes through a loop > where it tries to link a program that calls readline() with, in order, > "-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses", > "-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit > -lncurses" and "-ledit -lcurses". The first link that succeeds wil > determine which libraries are used. However, on some platforms with > dynamic libraries, the link will succeed as soon as readline() is > present -- but the shared library that contains it doesn't contain a > complete specification of all other libraries it needs at run-time > (the executable is expected to hold this information), and the program > fails at run-time even though it linked without any error message. On such a platform it would hardly be possible to detect anything with any reliably. A linker that links a program "succesfully" while the program really needs more libraries to be runnable isn't very useful. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> On such a platform it would hardly be possible to detect anything with any
> reliably. A linker that links a program "succesfully" while the program
> really needs more libraries to be runnable isn't very useful.
You're right, of course -- it's a bug in the linkage loader on the
platform in question. NetBSD/vax has it:
$ uname -a
NetBSD varg.i.eunet.no 1.5T NetBSD 1.5T (VARG) #4: Thu Apr 5 23:38:04 CEST 2001
root@varg.i.eunet.no:/usr/src/sys/arch/vax/compile/VARGvax
$ cat > foo.c
int main (int argc, char **argv) { readline(); }
$ cc -o foo foo.c
/tmp/ccFTO4Mu.o: Undefined symbol `_readline'referenced from text segment
collect2: ld returned 1 exit status
$ cc -o foo foo.c -ledit
$ echo $?
0
$ ./foo
/usr/libexec/ld.so: Undefined symbol "_tputs"in foo:/usr/lib/libedit.so.2.5
$ echo $?
1
$ ldd foo
foo: -ledit.2 => /usr/lib/libedit.so.2.5 (0x181b000) -lc.12 => /usr/lib/libc.so.12.74 (0x182d000)
$
-tih
--
The basic difference is this: hackers build things, crackers break them.
At 1:50 AM -0400 4/6/01, Tom Lane wrote: >"Henry B. Hotz" <hotz@jpl.nasa.gov> writes: > > Bottom line: 7.1RC1 passes most of the regression tests on > > NetBSD/macppc. > >The only thing that surprised me here was all of the warnings from >libreadline calls: > > >> tab-complete.c: In function `initialize_readline': > >> tab-complete.c:103: warning: assignment from incompatible pointer type > >> tab-complete.c: In function `psql_completion': > >> tab-complete.c:292: warning: passing arg 2 of `completion_matches' > >> from incompatible pointer type > >> tab-complete.c:296: warning: passing arg 2 of `completion_matches' > >> from incompatible pointer type > >What version of libreadline do you have installed, and how does it >declare completion_matches()? I have whatever is standard on NetBSD 1.5. I noticed that configure found a readline.h include file, but NetBSD doesn't integrate the current GNU implementation. I did not do a test of psql to see if the feature worked. I'm sure you could "fix" this problem if you installed GNU readline and referenced it in the build. Since Solaris had even worse issues with needing GNU support utilities installed this didn't seem like a big deal to me. OTOH it could confuse a new user. Signature held pending an ISO 9000 compliant signature design and approval process. h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu
> At 1:50 AM -0400 4/6/01, Tom Lane wrote:
> >"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
> > > Bottom line: 7.1RC1 passes most of the regression tests on
> > > NetBSD/macppc.
> >
> >The only thing that surprised me here was all of the warnings from
> >libreadline calls:
> >
> > >> tab-complete.c: In function `initialize_readline':
> > >> tab-complete.c:103: warning: assignment from incompatible pointer type
> > >> tab-complete.c: In function `psql_completion':
> > >> tab-complete.c:292: warning: passing arg 2 of `completion_matches'
> > >> from incompatible pointer type
> > >> tab-complete.c:296: warning: passing arg 2 of `completion_matches'
> > >> from incompatible pointer type
> >
> >What version of libreadline do you have installed, and how does it
> >declare completion_matches()?
$ uname -srm
NetBSD 1.5 i386
$ grep CPFunction /usr/include/readline.h
typedef char *CPFunction __P((const char *, int));
extern CPFunction *rl_completion_entry_function;
char **completion_matches __P((const char *, CPFunction *));
Putting the 'const' in the relevant PostgreSQL functions (diff against
7.1RC3 below) removes these warnings. I don't know what that does on
a machine using GNU readline ... I can check that in a day or two if
anyone's interested.
The NetBSD libedit-emulating-readline works just fine with psql even
without the warnings fixed -- they're harmless in this case.
Regards,
Giles
*** src/bin/psql/tab-complete.c-orig Mon Apr 2 05:17:32 2001
--- src/bin/psql/tab-complete.c Tue Apr 10 19:51:21 2001
***************
*** 70,80 **** /* Forward declaration of functions */
! static char **psql_completion(char *text, int start, int end);
! static char *create_command_generator(char *text, int state);
! static char *complete_from_query(char *text, int state);
! static char *complete_from_const(char *text, int state);
! static char *complete_from_list(char *text, int state); static PGresult *exec_query(char *query); char
*quote_file_name(char*text, int match_type, char *quote_pointer);
--- 70,80 ---- /* Forward declaration of functions */
! static char **psql_completion(const char *text, int start, int end);
! static char *create_command_generator(const char *text, int state);
! static char *complete_from_query(const char *text, int state);
! static char *complete_from_const(const char *text, int state);
! static char *complete_from_list(char const *text, int state); static PGresult *exec_query(char *query); char
*quote_file_name(char*text, int match_type, char *quote_pointer);
***************
*** 177,183 **** libraries completion_matches() function, so we don't have to worry about it. */ static char **
! psql_completion(char *text, int start, int end) { /* This is the variable we'll return. */ char
**matches= NULL;
--- 177,183 ---- libraries completion_matches() function, so we don't have to worry about it. */ static char **
! psql_completion(const char *text, int start, int end) { /* This is the variable we'll return. */ char
**matches= NULL;
***************
*** 796,802 **** as defined above. */ static char *
! create_command_generator(char *text, int state) { static int list_index, string_length;
--- 796,802 ---- as defined above. */ static char *
! create_command_generator(const char *text, int state) { static int list_index, string_length;
***************
*** 829,835 **** etc. */ static char *
! complete_from_query(char *text, int state) { static int list_index, string_length;
--- 829,835 ---- etc. */ static char *
! complete_from_query(const char *text, int state) { static int list_index, string_length;
***************
*** 877,883 **** SQL words that can appear at certain spot. */ static char *
! complete_from_list(char *text, int state) { static int string_length, list_index;
--- 877,883 ---- SQL words that can appear at certain spot. */ static char *
! complete_from_list(const char *text, int state) { static int string_length, list_index;
***************
*** 911,917 **** The string to be passed must be in completion_charp. */ static char *
! complete_from_const(char *text, int state) { (void) text; /* We don't care about what was entered
* already. */
--- 911,917 ---- The string to be passed must be in completion_charp. */ static char *
! complete_from_const(const char *text, int state) { (void) text; /* We don't care about what was
entered * already. */
On Mon, Apr 09, 2001 at 11:41:55AM -0700, Henry B. Hotz wrote: > At 1:50 AM -0400 4/6/01, Tom Lane wrote: ... > >What version of libreadline do you have installed, and how does it > >declare completion_matches()? > > I have whatever is standard on NetBSD 1.5. I noticed that configure > found a readline.h include file, but NetBSD doesn't integrate the > current GNU implementation. I did not do a test of psql to see if > the feature worked. > > I'm sure you could "fix" this problem if you installed GNU readline > and referenced it in the build. Since Solaris had even worse issues > with needing GNU support utilities installed this didn't seem like a > big deal to me. OTOH it could confuse a new user. Odd: I am using the standard NetBSD readline found in -ledit and it is fine.. Can it be a -1.5 vs -current difference? I have just stumbled across something which is broken though: NetBSD-1.5S/arm32: % ldd `which psql` /usr/local/pgsql/bin/psql: -lpq.2 => /usr/local/pgsql/lib/libpq.so.2.1 (0x2003b000) -lz.0 => /usr/lib/libz.so.0.2(0x20048000) -lcrypt.0 => /usr/lib/libcrypt.so.0.0 (0x20056000) -lresolv.1 => /usr/lib/libresolv.so.1.0(0x2005c000) -lm.0 => /usr/lib/libm.so.0.1 (0x20065000) -lutil.5 => /usr/lib/libutil.so.5.5(0x2008b000) -ledit.2 => /usr/lib/libedit.so.2.5 (0x20096000) -lc.12 => /usr/lib/libc.so.12.74(0x200ae000) NetBSD-1.5U/i386: % ldd `which psql` /usr/local/pgsql/bin/psql: -lcrypt.0 => /usr/lib/libcrypt.so.0 -lresolv.1 => /usr/lib/libresolv.so.1 -lpq.2 => /usr/local/pgsql/lib/libpq.so.2 -lz.0 => /usr/lib/libz.so.0 -lm.0 => /usr/lib/libm387.so.0 -lm.0 => /usr/lib/libm.so.0 -lutil.5 => /usr/lib/libutil.so.5 -ledit.2 => /usr/lib/libedit.so.2 -ltermcap.0=> /usr/lib/libtermcap.so.0 -lc.12 => /usr/lib/libc.so.12 -ltermcap is missing from arm32 - it's necessary if libedit is going to find _tgetent.. Investigating now.. Cheers, Patrick