test for PROJ lib uses 'src' instead of 'lib' dir

[kyngchaos@…]

When using --with-static-proj4, configure looks for libproj in $with_static_proj4/src instead of $with_static_proj4/lib:

      LIBS="-L$with_static_proj4/src $PROJ_LIB $ORIG_LIBS"
      echo "$as_me:$LINENO: checking for pj_init in -lproj" >&5

When proj is installed in an isolated location from other libraries, this will fail.

[warmerdam]

William, 

The hoary proj logic attempts to test for a variety of
configurations, including various ways of linking directly
against the PROJ.4 build tree (as opposed to install tree).
The first test is for /src which is in the build tree.  If 
that fails, it goes on to try /lib. 

PS. it would be easier to analyse references to the configure.in
instead of configure. 

From what I can see there is no problem.  If you are convinced there
is please re-open and provide more supporting information.

Thanks,

[kyngchaos@…]

Sorry about that - I somehow messed up my configure when I changed odbc to iodbc.  dunno how that happened.  It used to be a problem, but I forgot that it had been quietly fixed a while back.  In fact, I DID report this once already:

http://bugzilla.remotesensing.org/show_bug.cgi?id=871

that should be closed.

[warmerdam]

*** Bug 871 has been marked as a duplicate of this bug. ***

[brownrigg]

This bug slightly misnamed -- it is not the tests that are at issue, but it is the resultant Makefiles that erroneously use "src" instead of "lib".

This bug manifests quite readily when using --with-static-proj4=CUSTOM_PATH, where "CUSTOM_PATH" is some non-standard *installation* location of the PROJ library. It can be readily duplicated by 1) ensuring that the PROJ library is not present in any of the standard locations, and 2) ensuring is PROJ is installed somewhere and providing that location as part of the --with-static-proj4 switch. After running ./configure, it will be noted that the definition of the LIB macro in GDALmake.opt shows a "-L CUSTOM_PATH/src" directive, not a "-L CUSTOM_PATH/lib". Running make will demonstrate the configuration error by failing at the link stage with unresolved symbols from the PROJ library.

I agree that the logic in configure.in appears to be correct; in v1.5.0, the logic at lines 1849-1861 of configure.in *should* properly fix the LIB macro for the case described, and I am at a loss as to what is wrong, but the problem is demonstrable.

Excerpts from my config.log:

It was created by configure, which was generated by GNU Autoconf 2.61. Invocation command line was

$ ./configure --prefix=/usr/local/foo --without-ld-shared --with-libz=internal --with-png=internal --with-libtiff=internal --with-geotiff=internal --with-jpeg=internal --with-gif=internal --without-ogr --with-static-proj4=/opt/local --without-curl --without-sqlite3

...... note the first test for proj fails as expected .......

configure:26115: gcc -o conftest -g -O2 conftest.c -lproj -L/opt/local/src -lproj -ldl >&5 /usr/bin/ld: can't locate file for: -lproj collect2: ld returned 1 exit status configure:26121: $? = 1

..... and that the second test succeeds, as the logic in configure.in would predict...

configure:26139: result: no configure:26153: checking for pj_init in -lproj configure:26188: gcc -o conftest -g -O2 conftest.c -lproj -L/opt/local/lib -lproj -ldl >&5 configure:26194: $? = 0 configure:26212: result: yes

So, the config.log looks like all the tests were correctly performed OK, yet the GDALmake.opt will show otherwise.

[warmerdam]

I unpacked a copy of GDAL 1.5.0 on linux, and used this configure line:

./configure --with-static-proj4=$HOME/bld

This produced a GDALmake.opt with a LIBS line like:

LIBS	=	$(SDE_LIB) -L/wrk/home/warmerda/bld/lib -lproj -L/usr/local/lib -lgeos_c -I/usr/include -lsqlite3 -L/usr/lib -lexpat -L/usr/local/lib -lxerces-c -lpthread -lNCSEcw -lNCSCnet -lNCSUtil -ljasper -lhdf5 -ljpeg -ltiff -lpng -lnetcdf -lpq -L/usr/lib -lpq -lz  -lm -lrt -ldl  $(KAK_LIBS) $(DWG_LIBS) $(CURL_LIB)

Note -lproj is prefixed by -L/wrk/home/warmerda/bld/lib (not /src).

So, basically, everything seems to be working as I would expect, and I'm at a loss to reproduce the problem you see.