Using `./configure --with-sqlite3=custom_path` fails when lib dir isn't called exactly 'lib'

[jamesnunn]

I am building gdal to run on a server which requires dependencies to be downloaded to user space - in this case sqlite3 and sqlite3 development packages are downloaded to a home directory (using Scientific Linux 7):

  mkdir -p ~/local/sqlite 
  cd ~/local/sqlite 
  yumdownloader sqlite.x86_64 
  yumdownloader sqlite-devel.x86_64 
  rpm2cpio sqlite*.rpm | cpio -id 
  rpm2cpio sqlite-devel*.rpm | cpio -id 

The resulting top level tree looks like this:

  \-- sqlite 
    +-- usr 
        +-- bin 
        +-- include 
        +-- lib64 
        +-- share 

Note that the lib dir for 64bit RHEL-based systems is 'lib64'

Running the following command to configure a gdal build from source (on git mirror at 1e1d7cc):

  ./configure --with-sqlite3=/home/james/local/sqlite/usr

This results in the sqlite libs not being picked up. The issue is in the configure script (around line 27442) where the sqlite libs are hardcoded in 'lib' and not 'lib64'.

A simple workaround is creating a symlink to the lib64 dir :

  ln -s ~/sqlite/usr/lib64 <path_to_symlink> 
  ./configure --with-sqlite3=<path_to_symlink> 

[Even Rouault]

I'm not sure there's a way to address this cleanly. If you install sqlite from source and install in a custom location, this should go to prefix/lib/ and ./configure would find it. If you try to link to the system sqlite, that would work out of the box too. But the case where you take a package and unpackage it somewhere else than the root / directory is really an odd case. I'm tempted to close as wontfix unless somebody has a solution for that.

[jamesnunn]

Ah ok I didn't know you could put any local packages in the prefix dir and it would find it.

| ... really an odd case.

... we have a very picky sysadmin ;)