[postgis-users] "make check" failures w/ 1.3.1 on Mac OS 10.5

[William Kyngesburye]

Look at those /var/folders/... files.  The loader.err file has the  
last error details.  the numbered files (I forget the names after all  
my tests are succeeding) have the details for each failed test.  The  
'loader' file has the sql that was last run (tho it may not be from an  
error).

One difference is that I created the postgis_reg table and postgis- 
enabled it before running the tests, because I don't like giving  
superuser privileges to anybody, even me.  But then I had to edit the  
makefile so it uses the --nocreate option for run_test.  And edit  
run_test so it doesn't set lc_messages (a superuser setting, only  
needed for non-english languages really).

But, a postgres superuser run should work without that fuss.

On Nov 25, 2007, at 11:13 PM, John Cartwright wrote:

> Thanks for looking into this William and for your suggestion.  I've  
> implemented it, but am still getting 12 failures (all loader tests),  
> complaining that:
>
> ../loader/shp2pgsql: shape (.shp) or index files (.shx) can not be  
> opened.
>
> I've confirmed that the shapefiles are present and should be  
> accessible and that the test database (postgis_reg) is not present.
>
> Any ideas on what might be wrong?
>
> Thanks again for your help!
>
> --john
>
>
>
> On Nov 25, 2007, at 4:09 PM, William Kyngesburye wrote:
>
>> And once more... there was some leftover junk from the previous  
>> failed tests (a bunch of errors about relation already exists).   
>> After those were cleared out, all tests succeeded!
>>
>> On Nov 25, 2007, at 5:02 PM, William Kyngesburye wrote:
>>
>>> Sorry to keep replying to myself.  I think I see the problem:  
>>> get_uint32().  Leopard's libSystem now includes its own  
>>> get_uint32() (and get_int32()), so this is used in postgis instead  
>>> of the one in lwgeom_api.c.
>>>
>>> I can't find ANY reference to this in the Leopard headers or the  
>>> Xcode documentation, or in Apple's forums or mailing list  
>>> archives.  So I can't tell if it's compatible, it's certainly not  
>>> usable if there is no header declaration of it.
>>>
>>> So, renaming get_int32() and get_uint32() in Postgis did the trick  
>>> (I used pgis_get_int32 and pgis_get_uint32).  They're in these  
>>> files:
>>>
>>> liblwgeom.h
>>> lwcurve.c
>>> lwgeom_api.c
>>> lwgeom_pg.c
>>> lwline.c
>>> lwpoint.c
>>> lwpoly.c
>>>
>>> I now have 5/37 fails.  Time to check on those.
>>

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what  
does that remind me of?  Ah, yes - life."

- Marvin