[sqlite] 3.24.0 is 20% larger than 3.23.1
Hi, Our project did a SQLite version bump from 3.23.1 to 3.24.0 (identical build options), the /usr/lib/libsqlite3.so.0.8.6 lib increased by 20% ! 3.24.0 -rwxr-xr-x1 root root814112 Jun 10 15:31 /usr/lib/libsqlite3.so.0.8.6 (uses libm) 3.23.1 -rwxr-xr-x1 root root674800 Jun 6 20:35 /usr/lib/libsqlite3.so.0.8.6 (no libm reference) Also note the math library -lm was dynamically linked in 3.24.0 but not in 3.23.1 (via ldd). The only compile time option is -DSQLITE_ENABLE_COLUMN_METADATA Ref: https://github.com/astlinux-project/astlinux/blob/master/package/sqlite/sqlite.mk I have looked as Richard's thread "[sqlite] Size of the SQLite library Richard Hipp", but this seems much more than that. Has the default set of compile time options changed in 3.24.0 ? Any insight is appreciated. Lonnie ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] regression: SQLite 3.18.0 - editline configure no longer working
Hi, This commit: [bf28a55d] http://www.sqlite.org/src/fdiff?v1=cacf2616abf6e4a5=2893b823ecc86cea=0 Keeps libedit from be found and used. Using SQLite 3.18.0: --enable-editline --disable-readline -- checking editline/readline.h usability... yes checking editline/readline.h presence... yes checking for editline/readline.h... yes checking for library containing readline... no -- and no libedit support in /usr/bin/sqlite3 Reverting [bf28a55d] -- checking editline/readline.h usability... yes checking editline/readline.h presence... yes checking for editline/readline.h... yes checking for library containing readline... -ledit -- and libedit support is working again in /usr/bin/sqlite3 I don't understand why the libtinfo requirement was added for libedit. Lonnie ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] regression: --disable-static-shell no longer works
Hi, Cross-compiling SQLite from source on Linux using sqlite-autoconf-3110100, the --disable-static-shell option no longer works, a static-linked-sqlite3 binary is created. The regression appears to have occurred here: http://www.sqlite.org/src/fdiff?v1=1c16576507759608=29e2a6e8d0c5e327=0 This patch makes --disable-static-shell work again. --- sqlite-3110100/Makefile.am.orig 2016-03-10 10:12:23.0 -0600 +++ sqlite-3110100/Makefile.am 2016-03-10 10:14:14.0 -0600 @@ -6,8 +6,8 @@ libsqlite3_la_LDFLAGS = -no-undefined -version-info 8:6:8 bin_PROGRAMS = sqlite3 -sqlite3_SOURCES = shell.c sqlite3.c sqlite3.h -sqlite3_LDADD = @READLINE_LIBS@ +sqlite3_SOURCES = shell.c sqlite3.h +sqlite3_LDADD = @EXTRA_SHELL_OBJ@ @READLINE_LIBS@ sqlite3_DEPENDENCIES = @EXTRA_SHELL_OBJ@ sqlite3_CFLAGS = $(AM_CFLAGS) -DSQLITE_ENABLE_EXPLAIN_COMMENTS Hmmm, removing "sqlite3.c" from sqlite3_SOURCES works even without --disable-static-shell specified and a static sqlite3 binary is created as expected. The above patch fixes the regression for me, though it may not work with all possible permutations of builds. Possibly the line: -- EXTRA_sqlite3_SOURCES = sqlite3.c -- still needs to be added and referenced appropriately, currently EXTRA_sqlite3_SOURCES is no longer referenced. Lonnie
[sqlite] shell tool is no longer dynamically linked
On Nov 12, 2015, at 1:25 PM, Lonnie Abelbeck wrote: > When upgrading from SQLite 3.8.9 to 3.9.2 I noticed our binary image grew by > about 600KB, the culprit was the /usr/bin/sqlite3 shell tool is now > statically linked instead of dynamically linked as before. Much thanks to Dan for providing an elegant solution, I configured with --disable-static-shell with this patch... (and regenerate autoconf) Add the "--enable-static-shell" option to the amalgamation autoconf script. If set (the default) the compiled shell tool is statically linked against sqlite3.o. Otherwise, it is linked against libsqlite3.so. http://www.sqlite.org/src/info/499a02a34316cada Works perfectly for both cases, but most importantly: --disable-static-shell Thanks for the prompt, elegant solution. Lonnie
[sqlite] shell tool is no longer dynamically linked
Hi, I'm a developer with the AstLinux project and we cross-compile for x86 embedded hardware using the "autoconf" version of sqlite. When upgrading from SQLite 3.8.9 to 3.9.2 I noticed our binary image grew by about 600KB, the culprit was the /usr/bin/sqlite3 shell tool is now statically linked instead of dynamically linked as before. Binary image size matters to us, and 600KB of duplicated code is not good. We share the /usr/lib/libsqlite3.so library with a few packages. The change seems to have occurred here: Have the autoconf package build the shell tool with SQLite linked in statically. http://www.sqlite.org/src/info/31834c3aa7deeafe My current solution is to apply this build patch: --- sqlite-3090200/Makefile.in.orig 2015-11-12 10:34:16.0 -0600 +++ sqlite-3090200/Makefile.in 2015-11-12 10:37:16.0 -0600 @@ -107,7 +107,7 @@ $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \ $(libsqlite3_la_LDFLAGS) $(LDFLAGS) -o $@ PROGRAMS = $(bin_PROGRAMS) -am_sqlite3_OBJECTS = sqlite3-shell.$(OBJEXT) sqlite3-sqlite3.$(OBJEXT) +am_sqlite3_OBJECTS = sqlite3-shell.$(OBJEXT) $(top_builddir)/libsqlite3.la sqlite3_OBJECTS = $(am_sqlite3_OBJECTS) sqlite3_DEPENDENCIES = sqlite3_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ And that seems to restore the previous behavior to dynamically link the sqlite3 shell tool. It would be nice if like Fossil (--with-internal-sqlite), sqlite had a configure option to determine if the shell tool would be statically or dynamically linked, ex. --with-static-shell-tool I would expect sqlite would default to dynamically linked (if --enable-shared is passed), not sure why the change to static. Much appreciate the work here. Lonnie PS: Here is a related thread from another user a few weeks ago... sqlite 3.8.11 - binary size http://thread.gmane.org/gmane.comp.db.sqlite.general/97489
