Opened 14 years ago

Closed 12 years ago

Last modified 12 years ago

#1345 closed defect (invalid)

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

Reported by: kyngchaos@… Owned by: warmerdam
Priority: normal Milestone: 1.5.3
Component: ConfigBuild Version: 1.5.0
Severity: normal Keywords: proj

Description (last modified by warmerdam)

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.

Change History (10)

comment:1 Changed 14 years ago by warmerdam


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
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.


comment:2 Changed 14 years ago by 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:

that should be closed.

comment:3 Changed 14 years ago by warmerdam

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

comment:4 Changed 12 years ago by brownrigg

Component: defaultConfigBuild
Resolution: worksforme
Severity: majornormal
Status: closedreopened

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 appears to be correct; in v1.5.0, the logic at lines 1849-1861 of *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 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.

comment:5 Changed 12 years ago by warmerdam

Description: modified (diff)
Keywords: proj added

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.

comment:6 Changed 12 years ago by 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.

comment:7 Changed 12 years ago by brownrigg

Resolution: invalid
Status: reopenedclosed

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, when a path is given, is:

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

    LIBS="-L$with_static_proj4/src $PROJ_LIB $ORIG_LIBS"

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 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.

comment:8 Changed 12 years ago by warmerdam

Milestone: 1.6.0

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.

comment:9 Changed 12 years ago by warmerdam

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

comment:10 Changed 12 years ago by warmerdam


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

Note: See TracTickets for help on using tickets.