Another GUC for PROJSO or can we just figure out the PROJSO?

[robe]

So I started winnie's path to using proj 4.9.1 in prep for Windows 2.2 release with proj 4.9.1 (to take advantage of new geography goodness), and raster broke.

passed
  Test: test_gdal_to_raster ...passed
  Test: test_gdal_warp ...ERROR 6: Unable to load PROJ.4 library (libproj-0.dll), creation of
OGRCoordinateTransformation failed.
Assertion failed!

proj 4.9.1 creates dll libproj-9.dll

while the 4.8.0 series has libproj-0.dll

I think before libproj-0.dll is the default unless I override it with something else.

But now of course that default don't work with my 4.9.1 library.

So

SET PROJSO=libproj-9.dll

fixes the issue, but given I've got to ship to windows users who have every GIS thing under the sun, plus god knows what other versions of PostgreSQL/PostGIS running, I'd rather not muck with their system environment settings if I don't have to.

It would be really nice if raster was smart enough to figure out which proj it was compiled with, but barring that, I guess I can maybe live with a GUC for PROJSO.

[dustymugs]

Given the error message and more specifically OGRCoordinateTransformation, I think there's some conflict between proj4 and gdal. What gdal are you using? And which proj was compiled into gdal?

[robe]

Hmm I didn't realize gdal had a direct dependency on proj. I'm using GDAL 1.11.1

which is compiled with this script:

​http://svn.osgeo.org/postgis/buildbots/windows/mingw64/scripts/build_gdal.sh

I don't see any reference to PROJ in it.

[dustymugs]

GDAL definitely has proj4…

​https://trac.osgeo.org/gdal/wiki/ConfigOptions#PROJSO

Looking through my local gdal's config.log, I find entries like…

configure:28334: checking how to link PROJ.4 library
configure:28347: result: link dynamically.

[robe]

So it's hard-code to search for libproj-0.dll if not passed in according to that link. I had the same issue before I upgrade to proj 4.8.0 when I was using an older 4.6.something that comes in as libproj.dll. We skirted the issue cause upgrading to 4.8.0 made it not a requirement for me to set that variable.

[robe]

Well if this issue only affects me (ie a good chunk of windows users), I suppose I could just cheat and also distribute a copy of libproj-9.dll as libproj-0.dll. That isn't quite as annoying as having to deal with a GUC or environment variable.

though if it does affect others, we should consider doing it.

[dustymugs]

Your compiled GDAL has been hard coded to search for libproj-0.dll as that was found at compilation time. Can you recompile your GDAL?

[robe]

hmm hard to believe it found it at compilation since I don't think I had proj in my search path when I compiled. But I'll go head and recompile and see if it makes a difference.

[robe]

for completeness IRC dialog from EvenR:

<EvenR> robe2: proj dll is loaded through LoadLibrary()
<robe2> EvenR: so doesn't matter about compile time right?
<robe2> so issue is i installed 4.9.1
<robe2> and if I build postgis against 4.9.1 it still looks for libproj-0.dll
<robe2> unless I set PROJSO to libproj-9.dll
<EvenR> The default build doesn't need the include files or .lib of proj. But the --with-static-proj configure flag can be used for traditionnal linking
<EvenR> ah yes, the .so number has changed. hum

So it does seem like most likedly I'm just getting the default hard-coded name in GDAL 1.11.1. PErhaps GDAL 2.0 will come out before PostGIS 2.2. and I can up to that and it will have proj 4.9.1 as default and this will be a non-issue again.

I really don't want to statically compile in proj into my GDAL since I ship with GAL whatever files (which could be different between versions)

[robe]

Wait just a minute. Looks like EvenR tagged 2.0.0 today.

[robe]

Milestone renamed

[jratike80]

Is this ticket still relevant now when Proj has advanced to version 8?