Summary:ASTERISK-19751: asterisk fails to autoconfigure - cannot find sqlite3
Reporter:feyfre (feyfre)Labels:
Date Opened:2012-04-18 09:25:36Date Closed:2017-12-13 09:00:55.000-0600
Versions:10.3.0 Frequency of
Environment:Slackware64 and probably other x64 distros.Attachments:( 0) config.log-clean
( 1) config.log-keys
( 2) sqlite-seacrh.txt
Description:running configure this way:
CFLAGS="-O2 -fPIC" \
./configure \
--prefix=/usr \
--libdir=/usr/lib64 \
--sysconfdir=/etc \
--localstatedir=/var \
--mandir=/usr/man \
After a bunch of checkups got, next:
checking for speex_encode in -lspeex... no
checking for speex_preprocess_ctl in -lspeex... no
checking for speex_preprocess_ctl in -lspeexdsp... no
checking for sqlite_exec in -lsqlite... no
checking for sqlite3_open in -lsqlite3... no
configure: WARNING: *** Asterisk now uses SQLite3 for the internal Asterisk database.
configure: WARNING: *** Please install the SQLite3 development package.
However SQLite3 is installed.
(Will attach listing of sqlite3 related files on FS).
Comments:By: feyfre (feyfre) 2012-04-18 09:27:10.623-0500

Result of locate sqlite command.
As you see, sqlite3 is present.

By: feyfre (feyfre) 2012-04-19 05:56:13.332-0500

As it appeared configure script also cannot detect sqlite3 on the same system.

By: Matt Jordan (mjordan) 2012-04-20 13:25:02.139-0500

This appears to be a result of the parameters you've passed to the configure script.  What happens when you don't specify locations for the prefix or libdir, and simply run ./configure?

By: feyfre (feyfre) 2012-04-20 14:59:40.863-0500

Running ./configure without extra keys gives the same result.
command output differs only by first two lines(checking build/host system type).

By: feyfre (feyfre) 2012-04-20 15:00:47.291-0500

config.log after clean running of configure

By: feyfre (feyfre) 2012-04-20 15:03:08.185-0500

config.log after running configure with mentioned keys
With such keys most of software built on Slackware.

By: feyfre (feyfre) 2012-04-20 15:04:08.333-0500

Attached some configure logs. I hope it will help somehow.

By: Matt Jordan (mjordan) 2012-04-24 12:37:09.351-0500

Looking at your configure log, the reason why the configure script bombed out is this:

/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../x86_64-slackware-linux/bin/ld: cannot find -lsqlite

If you execute ld from that directory (which should end up being /usr/x86_64-slackware-linux/bin/ld) - can it find the sqlite library?

By: feyfre (feyfre) 2012-04-27 05:34:21.502-0500

> /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../x86_64-slackware-linux/bin/ld: cannot find -lsqlite

> If you execute ld from that directory (which should end up being /usr/x86_64-slackware-linux/bin/ld) - can it find the sqlite library?

This issue is not about SQLite. I have not installed any SQLite. I explicitly stated SQLite3. So ld -lsqlite will not find any sqlite libraries - it is intended to be so.

So, back to SQLite3.
I have got advice by Slackware maintainer. Workaround is pretty simple:
LDFLAGS="-ldl" ./confogure <otherargs>
It works.
Problem was in:
> configure:50059: checking for sqlite3_open in -lsqlite3
> configure:50094: gcc -o conftest -g -O2 -pthread   conftest.c -lsqlite3   -lm  >&5
> /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libsqlite3.so: undefined reference to `dlsym'
> /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libsqlite3.so: undefined reference to `dlerror'
> /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libsqlite3.so: undefined reference to `dlopen'
> /usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libsqlite3.so: undefined reference to `dlclose'
> collect2: ld returned 1 exit status
> configure:50101: $? = 1

So, solution is to tuneup configure to set extra libraries to probe with. I saw configure detects asound library with extra library dl. So the same should be for SQLite3. Use AST_EXT_LIB_CHECK ?
But I do not know how to modify configure.ac correctly, and how to regenerate configure correctly(running autoconf in source root generates very suspicious configure - about 5 times smaller than provided).

By: Matt Jordan (mjordan) 2012-04-27 07:39:34.480-0500

Sorry about that - I was looking at the wrong library!  Thanks for catching that and pointing out the correct issue here - that being that, for whatever reason, the sqlite3 library on SlackWare cannot locate the dynamic linker library using the standard shared object library search path.

That being said, I'm not convinced this is something that should be changed in Asterisk's default configure script.  The fact that your particular distro / machine configuration required the dynamic linker library to be specified in order to load the sqlite3 library seems rather odd.  As its not something that has to be specified for the vast majority of distros, this seems to be a rather isolated event.  And, as was pointed out, a workaround is available in the Asterisk configure script by explicitly specifying that the ld library should be linked.

You're more then welcome to solicit other opinions on this from other developers in #asterisk-dev or on the asterisk-dev mailing list.  They may have more insight into why this would be the case, and whether or not the configure script should be modified.