diff mbox series

[meta-darwin,11/21] sqlite3: fix Darwin nativesdk build (SONAME + shell link)

Message ID 20261014141209.488034-11-ecordonnier@snap.com
State New
Headers show
Series [meta-darwin,01/21] meta-darwin: bump layer series to wrynose (6.0.3) | expand

Commit Message

Etienne Cordonnier Oct. 14, 2026, 2:10 p.m. UTC 
From: Etienne Cordonnier <ecordonnier@snap.com>

sqlite's autosetup configure treats an unsupported SONAME mechanism as
a soft warning, but escalates to a fatal error when --soname was
explicitly requested. sqlite3.inc always passes --soname=legacy, and
Darwin's linker supports neither the GNU (-Wl,-soname) nor HP
(-Wl,+h) flag autosetup probes for, so do_configure aborts for the
macOS NDK nativesdk build. sqlite's configure already sets
-install_name for Mac targets independently of this flag, so dropping
it is sufficient.

That gets do_configure passing but do_compile then fails linking the
sqlite3 CLI shell:

  Undefined symbols for architecture x86_64: "_sqlite3_db_status64",
  "_sqlite3_enable_load_extension", "_sqlite3_load_extension"

The shell links with "-L. -lsqlite3" against the dylib just built in
the same directory. CC for this target always carries an extra -L for
the macOS SDK's own library dir (needed for other libSystem symbols),
and that same directory ships Apple's own libsqlite3 stub - missing
exactly these three newer/optional APIs - ahead of "-L." on the
command line, so the linker resolves -lsqlite3 against Apple's stub
instead of our library. Patch Makefile.in to link the shell against
$(libsqlite3.DLL) by path instead of via -l, which is unambiguous
regardless of -L search order. Scoped to darwin21 only.

AI-Generated: Claude Sonnet 5

Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
---
 ...ink-against-libsqlite3-by-path-not-l.patch | 41 +++++++++++++++++++
 recipes-support/sqlite/sqlite3_%.bbappend     | 17 ++++++++
 2 files changed, 58 insertions(+)
 create mode 100644 recipes-support/sqlite/files/0001-shell-link-against-libsqlite3-by-path-not-l.patch
 create mode 100644 recipes-support/sqlite/sqlite3_%.bbappend
diff mbox series

Patch

diff --git a/recipes-support/sqlite/files/0001-shell-link-against-libsqlite3-by-path-not-l.patch b/recipes-support/sqlite/files/0001-shell-link-against-libsqlite3-by-path-not-l.patch
new file mode 100644
index 0000000..e11155f
--- /dev/null
+++ b/recipes-support/sqlite/files/0001-shell-link-against-libsqlite3-by-path-not-l.patch
@@ -0,0 +1,41 @@ 
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: Etienne Cordonnier <ecordonnier@snap.com>
+Date: Fri, 19 Sep 2026 12:00:00 +0200
+Subject: [PATCH] Makefile.in: link sqlite3 shell against libsqlite3 by path,
+ not -l
+
+The shell binary links against the just-built shared library with
+"-L. -lsqlite3". On Darwin, CC always carries an extra -L for the
+macOS SDK's own system library directory (needed for other libSystem
+symbols), and that directory also happens to ship Apple's own
+libsqlite3 stub - which is missing sqlite3_load_extension,
+sqlite3_enable_load_extension and sqlite3_db_status64. Since that -L
+comes before "-L. -lsqlite3" on the command line, the linker resolves
+-lsqlite3 against Apple's stub instead of the library this recipe just
+built, and the shell fails to link with undefined symbols.
+
+Link directly against the just-built $(libsqlite3.DLL) by path instead
+of via -l, which is unambiguous regardless of -L search order. This is
+a no-op on non-Darwin targets, where "-L. -lsqlite3" and "./libsqlite3.so"
+resolve to the same file.
+
+Upstream-Status: Inappropriate [OE/Darwin specific]
+---
+ Makefile.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index 1111111111a..2222222222b 100644
+--- a/Makefile.in
++++ b/Makefile.in
+@@ -240,7 +240,7 @@
+ # https://sqlite.org/forum/forumpost/d80ecdaddd
+ ENABLE_STATIC_SHELL = @ENABLE_STATIC_SHELL@
+ sqlite3-shell-link-flags.1 = $(TOP)/sqlite3.c $(LDFLAGS) $(LDFLAGS.libsqlite3)
+-sqlite3-shell-link-flags.0 = $(LDFLAGS) -L. -lsqlite3 $(LDFLAGS.zlib) $(LDFLAGS.math)
++sqlite3-shell-link-flags.0 = $(LDFLAGS) ./$(libsqlite3.DLL) $(LDFLAGS.zlib) $(LDFLAGS.math)
+ sqlite3-shell-deps.1 = $(TOP)/sqlite3.c
+ sqlite3-shell-deps.0 = $(libsqlite3.DLL)
+ #
+--
+2.43.0
diff --git a/recipes-support/sqlite/sqlite3_%.bbappend b/recipes-support/sqlite/sqlite3_%.bbappend
new file mode 100644
index 0000000..74696d0
--- /dev/null
+++ b/recipes-support/sqlite/sqlite3_%.bbappend
@@ -0,0 +1,17 @@ 
+# Darwin's linker has neither -Wl,-soname nor HP's -Wl,+h; sqlite's own
+# configure already sets -install_name for Mac targets independently of
+# this flag, so don't force the ELF/HP-style soname check to be fatal here.
+EXTRA_OECONF:remove:darwin21 = "--soname=legacy"
+
+FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
+
+# The shell binary's "-L. -lsqlite3" link resolves against the macOS SDK's
+# own (feature-incomplete) libsqlite3 stub instead of the library just built
+# here - see the patch for details.
+SRC_URI:append:darwin21 = " \
+    file://0001-shell-link-against-libsqlite3-by-path-not-l.patch \
+"
+
+# The Darwin libraries are named libsqlite3.<version>.dylib, which the default
+# "${libdir}/*.so.*" doesn't match.
+FILES:lib${BPN}:append:darwin21 = " ${libdir}/libsqlite3*.dylib"