On Mon, Mar 03, 2008 at 10:39:57AM -0600, Norm Jacobs wrote: > Nicolas Williams wrote: > >On Fri, Feb 29, 2008 at 03:54:39PM -0800, Danek Duvall wrote: > > > >>On Fri, Feb 29, 2008 at 04:18:42PM -0600, Nicolas Williams wrote: > >> > >> > >>>http://cr.opensolaris.org/~nico//webrev-sqlite3-sfw-the-3rd/ > >>> > >>> - The relevant SQLite3 executables and shared objects are now built > >>> differently. Just patch the SQLite3 Makefile.in to build things the > >>> Solaris way. This turns out to be a trivial patch by taking > >>> advantage of the SQLite3 "amalgamation." > >>> > >>Is this actually simpler than Norm's supposed one-or-two-line fix? Or did > >>that not actually work? > >> > > > >Norm's fix (I didn't notice a fix) doesn't cause the executable nor the > >Tcl bindings to dynamically link with libsqlite3.so -- by default > >SQLite3 builds the library into the command and into the bindings. > > > Sorry I didn't get back online sooner. I traveling the last half of > Friday and opted for spending the weekend with my family. If you patch > in these two changes > > Makefile.in: > 595a596 > > $(LTINSTALL) libtclsqlite3.la `pwd` > > tclinstall.tcl: > 8c8 > < set LIBFILE .libs/libtclsqlite3[info sharedlibextension] > --- > > set LIBFILE libtclsqlite3[info sharedlibextension] > > You can use "make install" and get objects without references to your > workspace in them.
If I make no other changes then I don't need to make the above changes to avoid getting the .libs directory in the runpath. It is possible that the changes you suggest + the changes I was using will do what I wanted, but I ended up pursuing a much simpler approach, which you can see at the current webrev: http://cr.opensolaris.org/~nico/webrev-sqlite3-sfw-the-3rd/ > As for their build creating a monolithic > libtclsqlite3.so and executables, it appears that they are using > $(LIBOBJ) in more places than they should. The SQLite community has a penchant for static linking. For one thing it means that you're not dependent on someone else possibly changing versions of SQLite on you, and for another it means slightly faster code. But we're talking about integrating SQLite for Solaris consumers, so dynamically linking with libsqlite3.so is the right answer here. > I will try to look at your webrev later today. Thanks. Nico --
