On Fri, Feb 29, 2008 at 02:27:32PM -0600, Nicolas Williams wrote: > On Fri, Feb 29, 2008 at 12:13:29PM -0800, Norm Jacobs wrote: > > I took a copy of your Makefile.sfw less the patching, -R in LD_OPTIONS, > > and a couple of other minor things and a copy of the tarball and did a > > "make -f Makefile.sfw install". The resulting bits from the "cd $(VER) > > ; make DESTDIR=$(TOP)/tmp install" part of the build have the following > > RUNPATH and SONAME: > > Sorry, my previous reply was incorrect. > > Yes, what you did works, and I've already explained why. > > Again: SQLite3 doesn't make a sqlite3 executable nor a libtclsqlite3.so > shared object that link with libsqlite3.so. Instead those two include > *all* of libsqlite3 directly, as if by static linking.
To clarify: libtool doesn't add the .libs directory to libtclsqlite3.so's runpath because libtclsqlite3.so doesn't have a dependency on libsqlite3.so in the normal SQLite3 build. However, I believe that's not how we should want to build either libtclsqlite3.so, not the sqlite3 shell, not for Solaris. The reason being that it duplicates a lot object code. (And it's mildly dangerous, in that you could have an application that uses a Tcl interpreter and sqlite3 through it as well as directly, in which case you'd have two instances of libsqlite3 object code in the same process, which means you'll get corruption if you try to access the same DB from both places. Yes, this is extremely unlikely.)
