Opened 11 years ago

Closed 11 years ago

#2239 closed defect (invalid)

regress failure on postgresql 9.0 on windows

Reported by: robe Owned by: strk
Priority: blocker Milestone: PostGIS 2.1.0
Component: postgis Version: master
Keywords: windows Cc:

Description

I guess I've been zoned out, just noticed winnie is screaming when she tries to regress on 9.0 since strk's change in

r11175

psql:c:/jenkins/postgis/branches/2.1/regress/00-regress-install/share/contrib/postgis/postgis.sql:697: ERROR:  syntax error at or near "FOR"
LINE 16:  OPERATOR        13       <-> FOR ORDER BY pg_catalog.float_...

not sure why debbie isn't complaining. Perhaps only an issue on windows with order of includes or something or I have a dirty file somewhere.

Change History (13)

comment:1 by robe, 11 years ago

Owner: changed from pramsey to strk

comment:2 by robe, 11 years ago

I'm think this might have something to do with liblwgeom.a and liblwgeom.la and .h are being created in msys/local/lib. I just deleted them. This was the same issue I had with shp2pgsql-gui suddenly starting to fail after pramsey made an unrelated change.

I'm rerunning regress and will close this out if this fixes the issue, though not sure how to stop this in future. Its really bothersome that the files don't always get installed in msys/local/lib, and if I delete the files they don't usually come back on next run.

comment:3 by strk, 11 years ago

The change in r11175 has nothing to do with installation path of .a .la and .h files.

comment:4 by robe, 11 years ago

I know that. Neither did pramseys. It just seemes to happen when major changes in lwgeom or include locations changing. I'm just not sure how files end up being created there and why they don't always get created is my point.

comment:5 by robe, 11 years ago

Priority: criticalblocker

Well anyway clearing that folder doesn't help. I'll test locally in a bit, but it seems somehow your change screwed up (at least on mingw64) ability for it to differentiate between PostgreSQL 9.0 and above, because the install failure is happening because ORDER BY support is only valid for PostgreSQL 9.1+ since it relies on KNN logic introduced in 9.1 but its being left in for 9.0.

  OPERATOR        13       <-> FOR ORDER BY pg_catalog.float_...

Personally. I DON'T like this change you made on postgis.sql.in.c and other files that require c preprocessing.

Those files have C defines in it and to me they should have a .c extension to distinguish them from other .sql.in files that say go thru your perl preprocessor.

comment:6 by strk, 11 years ago

Alright, it could then have to do with SQLPP, can you check it's value in postgis/Makefile ?

$ grep ^SQLPP postgis/Makefile 
SQLPP = /usr/bin/cpp -traditional-cpp -P

Do you have cpp installed ?

comment:7 by strk, 11 years ago

Something to look at is also here: http://sourceforge.net/projects/sqlpp/

comment:9 by strk, 11 years ago

Another thing, cpp(1) manual talks about a -x switch that can be used to specify the language, can you check if adding -x c fixes the issue for you ?

comment:10 by strk, 11 years ago

Ah, final thing (I forgot this one). The ./configure script now also check for GPP (the Generic Pre Processor), but prefers cpp when found. I'd be curious to know if GPP would work fine instead.

Looking forward to the generated files and to account info to come and see what the issue is.

comment:11 by strk, 11 years ago

r11195 adds the -x c switch to the cpp call, does it change anything ?

comment:12 by robe, 11 years ago

No. You can take it out. I think the issue is that the

postgis.sql.in is being overwritten each call.

So the cpp stuff is working fine, since if I switch order of regress, 9.0 passes and the others fail.

comment:13 by robe, 11 years ago

Resolution: invalid
Status: newclosed

Nevermind. I'm pretty sure it was because for some reason the svn update did not delete the old postgis.sql.in and so didn't pull the new one.

I'll double-check the svn pull logic. It may be different from what I have on debbie. Deleting the file which forces the pull I think fixed the issue, so you can take out that -x c

Note: See TracTickets for help on using tickets.