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 Initial Version

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

Description

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 (0)

Note: See TracTickets for help on using tickets.