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.

[kyngchaos]

Ditto here, as the originator of this bug report. I don't remember what I did to my configure back then to cause the problem, so I can't help from that angle.

I have my PROJ in a custom, non-standard location (my OSX framework), and it doesn't exist in any standard location. --with-static-proj4= works.

[brownrigg]

After further checking, I have to conceed this is not a configuration problem, although its an unfortunate circumstance. I was trying to build a distribution using a pre-staged static PROJ library. However, on my production system, the PROJ library is also installed elsewhere, namely in /usr/local/lib, which is known by ldconfig on my machine.

The first test in the logic in configure.in, when a path is given, is:

  if test "x$with_static_proj4" = "xyes" ; then
...
  else

    LIBS="-L$with_static_proj4/src $PROJ_LIB $ORIG_LIBS"
    AC_CHECK_LIB(proj,pj_init,PROJ_STATIC=yes,PROJ_STATIC=no,)

Note the "/src". This produces the following probe in configure:

checking for pj_init in -lproj
configure:26122: gcc -o conftest -g -O2 -fPIC   conftest.c -lproj  -L/tmp/proj/src -lproj  -lm -lrt -ldl  >&5

Which will pass because of the implicit library paths, linking against the unintended library version, leaving LIB in the makefile configured with "...../src" rather than "...../lib"

As an aside, the resultant build does indeed run to completion in this case on my Linux box. It was failing under MacOSX because I had LDFLAGS also pointing to the PROJ dir, creating an implicit library path that allowed the same configure.in logic to pass, but which is a path that is unavailable to the build itself.

My apologies for re-opening the bug and troubling folks to re-examine the issue. I am marking the bug as invalid.

[warmerdam]

Excellent analysis!

Now, I'm going to reopen this ticket. I'd like to change the order of testing in trunk to do the more normal install tree scenario first so accidental success will give us that instead of the "build tree" case.

[warmerdam]

Well, my reopen failed, but I have patched in trunk (r13714).

[warmerdam]

This has caused me nightmares in my local gdal 1.5 tree too, so I've decided to back port it (r15074).