Undefined symbols: _sqlite3_prepare_v2

[ryandesign (Ryan Carsten Schmidt)]

MacPorts trunk (latest from today) fails to build on Tiger:

===> making all in src/registry2.0
cc -dynamiclib  registry.o util.o entry.o entryobj.o file.o fileobj.o ../cregistry/cregistry.a -o registry.dylib -L/System/Library/Frameworks/Tcl.framework/Versions/8.4 -ltclstub8.4   -lsqlite3
ld: Undefined symbols:
_sqlite3_prepare_v2
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: internal link edit command failed

[ryandesign (Ryan Carsten Schmidt)]

According to the ​SQLite older news page, sqlite3_prepare_v2 was added in sqlite 3.3.9 but on Tiger:

$ sqlite3 -version
3.1.3

[ryandesign (Ryan Carsten Schmidt)]

I just checked the released MacPorts-2.1.2 tarball and it does the same thing.

I don't understand why configure claims:

checking for SQLite >= 3003011... yes

When:

$ grep -C 1 '#.*SQLITE_VERSION_NUMBER' /usr/include/sqlite3.h 
*/
#ifdef SQLITE_VERSION_NUMBER
# undef SQLITE_VERSION_NUMBER
#endif
#define SQLITE_VERSION_NUMBER 3000000

(For SQLite 3.1.3, SQLITE_VERSION_NUMBER should really have been 3001003 but there was a bug in the SQLite configure script for awhile where ​SQLITE_VERSION_NUMBER was always 3000000.)

This is a new installation of Tiger set up just a week ago for MacPorts testing purposes; nothing's been installed besides the OS and all updates and Xcode 2.5.

[ryandesign (Ryan Carsten Schmidt)]

I have traced the problem to me having set CPP=/usr/bin/cpp while running ./configure. If I instead set CPP="/usr/bin/cc -E" or leave the configure script to decide to use gcc -E then the SQLite version gets properly detected. I guess that makes this a user error, but it certainly surprised this user.

[neverpanic (Clemens Lang)]

This works for other Tiger users and is sufficiently checked for in configure. If you want to improve this, feel free to do so yourself. I (as the guy who added sqlite3_prepare_v2) will not follow up on this ticket.

[ryandesign (Ryan Carsten Schmidt)]

Setting CPP=/usr/bin/cpp, as I had been doing in my build script that I use, also causes a (different) build error on Mavericks, so apparently it's a case of "don't do that" (use CPP="/usr/bin/cc -E" instead).