Opened 8 years ago

Last modified 8 years ago

#6515 closed defect

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

Reported by: jamesnunn Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: unspecified
Severity: normal Keywords:
Cc:

Description (last modified by 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> 

Change History (1)

comment:1 by jamesnunn, 8 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.