[PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Guðni Már Gilbert]

This update includes major change in how it is built.
Instead of autotools, autosetup is used.

Autosetup (https://msteveb.github.io/autosetup/) claims to be
* Replacement for autoconf in many situations
However it also claims NOT to
* Intended to replace all possible uses of autoconf
This means that some autoconf features are not available.

Recipe changes:
* stop inheriting autotools and define B, do_configure and do_install
* depend on zlib unconditionally, autoconf cannot be preconfigured in
  similar way as autotools
* update packageconfig options to match new syntax
* libedit is detected with ncurses linking options (as seen in
  do_configure log)
* backport rpaths fix
* define soname to avoid file-rdeps QA error due to wrong library name
* add hack to force cross-compilation in native case to link against
  zlib in sysroot and thus avoid crashes when sstate-cache from different
  distro is used
* clean B for do_configure as the new Makefiles do not seem to properly
  retrigger build if configuration changes

Kudos to Peter Marko for the initial work on upgrading SQLite

Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com>
---
 meta/recipes-support/sqlite/sqlite3.inc       | 43 ++++++++++---
 ...rpath-configure-script-flag-to-addre.patch | 60 +++++++++++++++++++
 .../{sqlite3_3.48.0.bb => sqlite3_3.50.2.bb}  |  4 +-
 3 files changed, 98 insertions(+), 9 deletions(-)
 create mode 100644 meta/recipes-support/sqlite/sqlite3/0001-Add-the-disable-rpath-configure-script-flag-to-addre.patch
 rename meta/recipes-support/sqlite/{sqlite3_3.48.0.bb => sqlite3_3.50.2.bb} (53%)

diff --git a/meta/recipes-support/sqlite/sqlite3.inc b/meta/recipes-support/sqlite/sqlite3.inc
index 28a33282ae..3251d310fb 100644
--- a/meta/recipes-support/sqlite/sqlite3.inc
+++ b/meta/recipes-support/sqlite/sqlite3.inc
@@ -14,34 +14,37 @@ def sqlite_download_version(d):
 SQLITE_PV = "${@sqlite_download_version(d)}"
 
 S = "${UNPACKDIR}/sqlite-autoconf-${SQLITE_PV}"
+B = "${WORKDIR}/build"
 
-UPSTREAM_CHECK_URI = "http://www.sqlite.org/"
+UPSTREAM_CHECK_URI = "https://www.sqlite.org/"
 UPSTREAM_CHECK_REGEX = "releaselog/(?P<pver>(\d+[\.\-_]*)+)\.html"
 
 CVE_PRODUCT = "sqlite"
 
-inherit autotools pkgconfig siteinfo
+inherit pkgconfig siteinfo
+
+# zlib is autodetected and gets to sysroots as transitive dependency, make this deterministic
+DEPENDS = "zlib"
 
 # enable those which are enabled by default in configure
 PACKAGECONFIG ?= "fts4 fts5 rtree dyn_ext"
 PACKAGECONFIG:class-native ?= "fts4 fts5 rtree dyn_ext"
 
-PACKAGECONFIG[editline] = "--enable-editline,--disable-editline,libedit"
-PACKAGECONFIG[readline] = "--enable-readline,--disable-readline,readline ncurses"
+PACKAGECONFIG[editline] = "--enable-editline --with-readline-header=${includedir}/editline/readline.h,--disable-editline,libedit ncurses"
+PACKAGECONFIG[readline] = "--enable-readline --with-readline-header=${includedir}/readline/readline.h,--disable-readline,readline ncurses"
 PACKAGECONFIG[fts3] = "--enable-fts3,--disable-fts3"
 PACKAGECONFIG[fts4] = "--enable-fts4,--disable-fts4"
 PACKAGECONFIG[fts5] = "--enable-fts5,--disable-fts5"
 PACKAGECONFIG[rtree] = "--enable-rtree,--disable-rtree"
 PACKAGECONFIG[session] = "--enable-session,--disable-session"
-PACKAGECONFIG[dyn_ext] = "--enable-dynamic-extensions,--disable-dynamic-extensions"
-PACKAGECONFIG[zlib] = ",,zlib"
-
-CACHED_CONFIGUREVARS += "${@bb.utils.contains('PACKAGECONFIG', 'zlib', '', 'ac_cv_search_deflate=no',d)}"
+PACKAGECONFIG[dyn_ext] = "--enable-load-extension,--disable-load-extension"
 
 EXTRA_OECONF = " \
     --enable-shared \
     --enable-threadsafe \
+    --disable-rpath \
     --disable-static-shell \
+    --soname=${PV} \
 "
 
 # pread() is in POSIX.1-2001 so any reasonable system must surely support it
@@ -65,4 +68,28 @@ FILES:lib${BPN}-staticdev = "${libdir}/lib*.a"
 
 AUTO_LIBNAME_PKGS = "${MLPREFIX}lib${BPN}"
 
+do_configure() {
+    ${S}/configure \
+        --build=${BUILD_SYS} \
+        --host=${TARGET_SYS} \
+        --prefix=${prefix} \
+        --bindir=${bindir} \
+        --libdir=${libdir} \
+        --includedir=${includedir} \
+        --mandir=${mandir} \
+        ${EXTRA_OECONF} \
+        ${PACKAGECONFIG_CONFARGS}
+}
+do_configure[cleandirs] = "${B}"
+
+do_install() {
+    oe_runmake DESTDIR=${D} install
+
+    # binaries are stripped during installation when not cross-compiling, take the unstripped ones instead
+    if [ "${BUILD_SYS}" = "${TARGET_SYS}" ]; then
+        install -m 0644 ${B}/sqlite3 ${D}${bindir}
+        install -m 0644 ${B}/libsqlite3.so ${D}${libdir}/libsqlite3.so.${PV}
+    fi
+}
+
 BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-support/sqlite/sqlite3/0001-Add-the-disable-rpath-configure-script-flag-to-addre.patch b/meta/recipes-support/sqlite/sqlite3/0001-Add-the-disable-rpath-configure-script-flag-to-addre.patch
new file mode 100644
index 0000000000..9625b3045d
--- /dev/null
+++ b/meta/recipes-support/sqlite/sqlite3/0001-Add-the-disable-rpath-configure-script-flag-to-addre.patch
@@ -0,0 +1,60 @@
+From 509f5574267c8353a10ff81e96d8393248810b80 Mon Sep 17 00:00:00 2001
+From: stephan <stephan@noemail.net>
+Date: Sun, 22 Jun 2025 22:48:11 +0000
+Subject: [PATCH] Add the --disable-rpath configure script flag to address
+ [forum:13cac3b56516f849 | forum post 13cac3b56516f849].
+
+FossilOrigin-Name: a59d9bb25e518f5d79f654615b92f6c50cfb704b5abee0f820912644b89366c5
+
+Upstream-Status: Backport [https://github.com/sqlite/sqlite/commit/87c807c6dd4df67328919fa28e89a06839e634fe]
+Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com>
+---
+ autosetup/sqlite-config.tcl | 18 +++++++++---------
+ 1 file changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/autosetup/sqlite-config.tcl b/autosetup/sqlite-config.tcl
+index 85fe414382..8409dbdd81 100644
+--- a/autosetup/sqlite-config.tcl
++++ b/autosetup/sqlite-config.tcl
+@@ -334,8 +334,8 @@ proc sqlite-configure {buildMode configScript} {
+           => {Link the sqlite3 shell app against the DLL instead of embedding sqlite3.c}
+       }
+       {canonical autoconf} {
+-        # A potential TODO without a current use case:
+-        #rpath=1 => {Disable use of the rpath linker flag}
++        rpath=1 => {Disable use of the rpath linker flag}
++
+         # soname: https://sqlite.org/src/forumpost/5a3b44f510df8ded
+         soname:=legacy
+           => {SONAME for libsqlite3.so. "none", or not using this flag, sets no
+@@ -2119,7 +2119,6 @@ proc sqlite-handle-tcl {} {
+ ########################################################################
+ # Handle the --enable/disable-rpath flag.
+ proc sqlite-handle-rpath {} {
+-  proj-check-rpath
+   # autosetup/cc-shared.tcl sets the rpath flag definition in
+   # [get-define SH_LINKRPATH], but it does so on a per-platform basis
+   # rather than as a compiler check. Though we should do a proper
+@@ -2128,12 +2127,13 @@ proc sqlite-handle-rpath {} {
+   # for which sqlite-env-is-unix-on-windows returns a non-empty
+   # string.
+ 
+-#  if {[proj-opt-truthy rpath]} {
+-#    proj-check-rpath
+-#  } else {
+-#    msg-result "Disabling use of rpath."
+-#    define LDFLAGS_RPATH ""
+-#  }
++  # https://sqlite.org/forum/forumpost/13cac3b56516f849
++  if {[proj-opt-truthy rpath]} {
++    proj-check-rpath
++  } else {
++    msg-result "Disabling use of rpath."
++    define LDFLAGS_RPATH ""
++  }
+ }
+ 
+ ########################################################################
+-- 
+2.43.0
+
diff --git a/meta/recipes-support/sqlite/sqlite3_3.48.0.bb b/meta/recipes-support/sqlite/sqlite3_3.50.2.bb
similarity index 53%
rename from meta/recipes-support/sqlite/sqlite3_3.48.0.bb
rename to meta/recipes-support/sqlite/sqlite3_3.50.2.bb
index bd2ac6614d..abb54e839b 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.48.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.50.2.bb
@@ -4,5 +4,7 @@ LICENSE = "PD"
 LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66"
 
 SRC_URI = "http://www.sqlite.org/2025/sqlite-autoconf-${SQLITE_PV}.tar.gz"
-SRC_URI[sha256sum] = "ac992f7fca3989de7ed1fe99c16363f848794c8c32a158dafd4eb927a2e02fd5"
+SRC_URI[sha256sum] = "84a616ffd31738e4590b65babb3a9e1ef9370f3638e36db220ee0e73f8ad2156"
+
+SRC_URI += "file://0001-Add-the-disable-rpath-configure-script-flag-to-addre.patch"
 
-- 
2.43.0

Re: [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Guðni Már Gilbert]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

Previous discussion thread: https://lists.openembedded.org/g/openembedded-core/topic/113866512

I built today core-image-minimal on latest master (Git HEAD for reference: https://git.openembedded.org/openembedded-core/commit/?id=cf89a121f93e404485983b92abc88a46a7f24890) and also upgraded SQLite from 3.50.1 to 3.50.2 for bug fixes.

So far I haven't been able to reproduce the issue with pseudo I saw with SQLite 3.50.1, and I wonder if the autobuilder/test system will catch any issues?

[-- Attachment #2: Type: text/html, Size: 827 bytes --]

RE: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Marko, Peter]

[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]

I don’t think it’s worth to send the same patch again.
It did not fail on normal autobuilder builds which build images and testimages.
Also my private builds were fine before I sent my patches.

The problem is in oe-selftest run on autobuilder, where the conditions are different.
Oe-selftest is a huge beast (taking more than a day on regular machines) and AB config is hard to decode.
I’ll eventually build it myself as part of ppc-32 support, but I’m not so far yet.

Peter

From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Guðni Már Gilbert via lists.openembedded.org
Sent: Saturday, July 12, 2025 16:12
To: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

Previous discussion thread: https://lists.openembedded.org/g/openembedded-core/topic/113866512

I built today core-image-minimal on latest master (Git HEAD for reference: https://git.openembedded.org/openembedded-core/commit/?id=cf89a121f93e404485983b92abc88a46a7f24890) and also upgraded SQLite from 3.50.1 to 3.50.2 for bug fixes.

So far I haven't been able to reproduce the issue with pseudo I saw with SQLite 3.50.1, and I wonder if the autobuilder/test system will catch any issues?

[-- Attachment #2: Type: text/html, Size: 5086 bytes --]

Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Gyorgy Sarvari]

On 7/12/25 16:25, Peter Marko via lists.openembedded.org wrote:
>
> I don’t think it’s worth to send the same patch again.
>
> It did not fail on normal autobuilder builds which build images and
> testimages.
>
> Also my private builds were fine before I sent my patches.
>
>  
>
> The problem is in oe-selftest run on autobuilder, where the conditions
> are different.
>
> Oe-selftest is a huge beast (taking more than a day on regular
> machines) and AB config is hard to decode.
>
> I’ll eventually build it myself as part of ppc-32 support, but I’m not
> so far yet.
>

I managed reproduce this on my machine.

1. Apply this patch, and do at least 50% of world build (the more the
better, I think).
2. Set BB_NUMBER_THREADS = "100" in local.conf
3. Delete the tmp folder (but keep the sstate cache, the idea is to
abuse it)
4. Start "bitbake world" again, and let it run until it runs out of
setscene tasks, or fails.
5. If it doesn't fail, stop the build and go back to step 3.

I don't know how frequently this reproduces, but, it looks at  least 3
out of 4 tries fail on my end.
I will try to look at it as time allows, but if you have experience with
sqlite, don't hold yourself back, feel free to look into this. I start
blind here.

(Btw that 100 threads for setscene isn't a killer, I'm using an aging
Ryzen 5600G.)

>  
>
> Peter
>
>  
>
> *From:*openembedded-core@lists.openembedded.org
> <openembedded-core@lists.openembedded.org> *On Behalf Of *Guðni Már
> Gilbert via lists.openembedded.org
> *Sent:* Saturday, July 12, 2025 16:12
> *To:* openembedded-core@lists.openembedded.org
> *Subject:* Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2
>
>  
>
> Previous discussion thread:
> https://lists.openembedded.org/g/openembedded-core/topic/113866512
>
>  
>
> I built today /core-image-minimal/ on latest master (Git HEAD for
> reference:
> https://git.openembedded.org/openembedded-core/commit/?id=cf89a121f93e404485983b92abc88a46a7f24890)
> and also upgraded SQLite from 3.50.1 to 3.50.2 for bug fixes.
>
>  
>
> So far I haven't been able to reproduce the issue with pseudo I saw
> with SQLite 3.50.1, and I wonder if the autobuilder/test system will
> catch any issues?
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#220192): https://lists.openembedded.org/g/openembedded-core/message/220192
> Mute This Topic: https://lists.openembedded.org/mt/114116736/6084445
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [skandigraun@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Gyorgy Sarvari]

On 8/31/25 20:54, Gyorgy Sarvari via lists.openembedded.org wrote:
> On 7/12/25 16:25, Peter Marko via lists.openembedded.org wrote:
>> I don’t think it’s worth to send the same patch again.
>>
>> It did not fail on normal autobuilder builds which build images and
>> testimages.
>>
>> Also my private builds were fine before I sent my patches.
>>
>>  
>>
>> The problem is in oe-selftest run on autobuilder, where the conditions
>> are different.
>>
>> Oe-selftest is a huge beast (taking more than a day on regular
>> machines) and AB config is hard to decode.
>>
>> I’ll eventually build it myself as part of ppc-32 support, but I’m not
>> so far yet.
>>
> I managed reproduce this on my machine.
>
> 1. Apply this patch, and do at least 50% of world build (the more the
> better, I think).
> 2. Set BB_NUMBER_THREADS = "100" in local.conf
> 3. Delete the tmp folder (but keep the sstate cache, the idea is to
> abuse it)
> 4. Start "bitbake world" again, and let it run until it runs out of
> setscene tasks, or fails.
> 5. If it doesn't fail, stop the build and go back to step 3.
>
> I don't know how frequently this reproduces, but, it looks at  least 3
> out of 4 tries fail on my end.
> I will try to look at it as time allows, but if you have experience with
> sqlite, don't hold yourself back, feel free to look into this. I start
> blind here.
>
> (Btw that 100 threads for setscene isn't a killer, I'm using an aging
> Ryzen 5600G.)

A few additions:
- It reproduces 100% of the time currently on my machine
- The thread number modification isn't actually required
- It seems to fail always at the same place - if I restart bitbake world
after a failure without deleting the tmp folder, it fails again. At this
time I struggle capturing the exact task.
- The error message from pseudo is "error while loading shared
libraries: libsqlite3.so.3.50.2: cannot open shared object file: No such
file or directory"
- At the time when this error occurs, there is indeed no such file in
sysroots-components folder
- If I run "bitbake sqlite3-native" after such a failure, and do bitbake
world again, it succeeds.
- I wonder if the reason for the behavior change is the "--soname=${PV}"
argument in the new recipe. ldd shows that pseudo is linked against
"libsqlite3.so.3.50.2", but before this patch it linked against
"libsqlite3.so.0". I suspect that until now it fell back to the host
OS's libsqlite, and that's why it didn't fail. (My main OS has 3.50.4,
so it doesn't match)

But I will stop spamming for the day, will try that tomorrow, unless
someone else is faster.

>>  
>>
>> Peter
>>
>>  
>>
>> *From:*openembedded-core@lists.openembedded.org
>> <openembedded-core@lists.openembedded.org> *On Behalf Of *Guðni Már
>> Gilbert via lists.openembedded.org
>> *Sent:* Saturday, July 12, 2025 16:12
>> *To:* openembedded-core@lists.openembedded.org
>> *Subject:* Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2
>>
>>  
>>
>> Previous discussion thread:
>> https://lists.openembedded.org/g/openembedded-core/topic/113866512
>>
>>  
>>
>> I built today /core-image-minimal/ on latest master (Git HEAD for
>> reference:
>> https://git.openembedded.org/openembedded-core/commit/?id=cf89a121f93e404485983b92abc88a46a7f24890)
>> and also upgraded SQLite from 3.50.1 to 3.50.2 for bug fixes.
>>
>>  
>>
>> So far I haven't been able to reproduce the issue with pseudo I saw
>> with SQLite 3.50.1, and I wonder if the autobuilder/test system will
>> catch any issues?
>>
>>
>>
>>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#222635): https://lists.openembedded.org/g/openembedded-core/message/222635
> Mute This Topic: https://lists.openembedded.org/mt/114116736/6084445
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [skandigraun@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Gyorgy Sarvari]

On 8/31/25 22:24, Gyorgy Sarvari via lists.openembedded.org wrote:
> On 8/31/25 20:54, Gyorgy Sarvari via lists.openembedded.org wrote:
>> On 7/12/25 16:25, Peter Marko via lists.openembedded.org wrote:
>>> I don’t think it’s worth to send the same patch again.
>>>
>>> It did not fail on normal autobuilder builds which build images and
>>> testimages.
>>>
>>> Also my private builds were fine before I sent my patches.
>>>
>>>  
>>>
>>> The problem is in oe-selftest run on autobuilder, where the conditions
>>> are different.
>>>
>>> Oe-selftest is a huge beast (taking more than a day on regular
>>> machines) and AB config is hard to decode.
>>>
>>> I’ll eventually build it myself as part of ppc-32 support, but I’m not
>>> so far yet.
>>>
>> I managed reproduce this on my machine.
>>
>> 1. Apply this patch, and do at least 50% of world build (the more the
>> better, I think).
>> 2. Set BB_NUMBER_THREADS = "100" in local.conf
>> 3. Delete the tmp folder (but keep the sstate cache, the idea is to
>> abuse it)
>> 4. Start "bitbake world" again, and let it run until it runs out of
>> setscene tasks, or fails.
>> 5. If it doesn't fail, stop the build and go back to step 3.
>>
>> I don't know how frequently this reproduces, but, it looks at  least 3
>> out of 4 tries fail on my end.
>> I will try to look at it as time allows, but if you have experience with
>> sqlite, don't hold yourself back, feel free to look into this. I start
>> blind here.
>>
>> (Btw that 100 threads for setscene isn't a killer, I'm using an aging
>> Ryzen 5600G.)
> A few additions:
> - It reproduces 100% of the time currently on my machine
> - The thread number modification isn't actually required
> - It seems to fail always at the same place - if I restart bitbake world
> after a failure without deleting the tmp folder, it fails again. At this
> time I struggle capturing the exact task.
> - The error message from pseudo is "error while loading shared
> libraries: libsqlite3.so.3.50.2: cannot open shared object file: No such
> file or directory"
> - At the time when this error occurs, there is indeed no such file in
> sysroots-components folder
> - If I run "bitbake sqlite3-native" after such a failure, and do bitbake
> world again, it succeeds.
> - I wonder if the reason for the behavior change is the "--soname=${PV}"
> argument in the new recipe. ldd shows that pseudo is linked against
> "libsqlite3.so.3.50.2", but before this patch it linked against
> "libsqlite3.so.0". I suspect that until now it fell back to the host
> OS's libsqlite, and that's why it didn't fail. (My main OS has 3.50.4,
> so it doesn't match)
>
> But I will stop spamming for the day, will try that tomorrow, unless
> someone else is faster.

I'm 97.89% confident that I figured out the problem, but I could use
some advice, how to solve it.
So the issue is indeed that pseudo-native has a runtime dependency on
sqlite3, but currently it isn't guaranteed to be available in the Yocto
folders.

Until now pseudo was linked to unversioned sqlite libs, and if it
couldn't find it in the Yocto folders, it just grabbed the one from the
host. But now that it is linked to a versioned library, it needs exact
version.
Generally speaking the sysroots-components/$BUILD_ARCH/sqlite3-native
folder should be populated by the time pseudo-native is first used,
which doesn't happen always.

So I tried to add the following to the pseudo recipe:

python __anonymous () {
    if d.getVar("PN").endswith("-native"):
        d.appendVarFlag('do_populate_sysroot', 'depends', '
sqlite3-native:do_populate_sysroot')
}

I have also tried
do_populate_sysroot[depends] += 'sqlite3-native:do_populate_sysroot'

However when building from sstate cache, these don't seem to be
deterministic - rarely it seems to work, but more often pseudo-native is
populated before sqlite3-native, and just fails still.

I wonder, are these inter-task dependencies ignored when populating
sysroots from sstate cache?
Or should I rather add the dependency to base.bbclass next to pseudo-
(if fakeroot == pseudo, then add sqlite3-native:do_populate_sysroot as a
dep too)? 
Or am I completely misguided here?

Thanks

>>>  
>>>
>>> Peter
>>>
>>>  
>>>
>>> *From:*openembedded-core@lists.openembedded.org
>>> <openembedded-core@lists.openembedded.org> *On Behalf Of *Guðni Már
>>> Gilbert via lists.openembedded.org
>>> *Sent:* Saturday, July 12, 2025 16:12
>>> *To:* openembedded-core@lists.openembedded.org
>>> *Subject:* Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2
>>>
>>>  
>>>
>>> Previous discussion thread:
>>> https://lists.openembedded.org/g/openembedded-core/topic/113866512
>>>
>>>  
>>>
>>> I built today /core-image-minimal/ on latest master (Git HEAD for
>>> reference:
>>> https://git.openembedded.org/openembedded-core/commit/?id=cf89a121f93e404485983b92abc88a46a7f24890)
>>> and also upgraded SQLite from 3.50.1 to 3.50.2 for bug fixes.
>>>
>>>  
>>>
>>> So far I haven't been able to reproduce the issue with pseudo I saw
>>> with SQLite 3.50.1, and I wonder if the autobuilder/test system will
>>> catch any issues?
>>>
>>>
>>>
>>>
>>
>>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#222636): https://lists.openembedded.org/g/openembedded-core/message/222636
> Mute This Topic: https://lists.openembedded.org/mt/114116736/6084445
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [skandigraun@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Alexander Kanavin]

On Mon, 1 Sept 2025 at 12:29, Gyorgy Sarvari via
lists.openembedded.org <skandigraun=gmail.com@lists.openembedded.org>
wrote:
> I'm 97.89% confident that I figured out the problem, but I could use
> some advice, how to solve it.
> So the issue is indeed that pseudo-native has a runtime dependency on
> sqlite3, but currently it isn't guaranteed to be available in the Yocto
> folders.
>
> Until now pseudo was linked to unversioned sqlite libs, and if it
> couldn't find it in the Yocto folders, it just grabbed the one from the
> host. But now that it is linked to a versioned library, it needs exact
> version.
> Generally speaking the sysroots-components/$BUILD_ARCH/sqlite3-native
> folder should be populated by the time pseudo-native is first used,
> which doesn't happen always.
>
> So I tried to add the following to the pseudo recipe:
>
> python __anonymous () {
>     if d.getVar("PN").endswith("-native"):
>         d.appendVarFlag('do_populate_sysroot', 'depends', '
> sqlite3-native:do_populate_sysroot')
> }
>
> I have also tried
> do_populate_sysroot[depends] += 'sqlite3-native:do_populate_sysroot'
>
> However when building from sstate cache, these don't seem to be
> deterministic - rarely it seems to work, but more often pseudo-native is
> populated before sqlite3-native, and just fails still.
>
> I wonder, are these inter-task dependencies ignored when populating
> sysroots from sstate cache?
> Or should I rather add the dependency to base.bbclass next to pseudo-
> (if fakeroot == pseudo, then add sqlite3-native:do_populate_sysroot as a
> dep too)?
> Or am I completely misguided here?

I'm afraid we have not yet gotten to the bottom of the problem.

First, pseudo linking with libsqlite3.so.3.50.2 is wrong. It should
continue to link with libsqlite3.so.0 like before.

That said, non-deterministically falling through to the host libsqlite
is wrong as well, it just wasn't previously exposed. We need to figure
out this one first, and fix it properly, and only then address the
pseudo linking issue above.

Alex

Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Alexander Kanavin]

On Mon, 1 Sept 2025 at 13:15, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
> That said, non-deterministically falling through to the host libsqlite
> is wrong as well, it just wasn't previously exposed. We need to figure
> out this one first, and fix it properly, and only then address the
> pseudo linking issue above.

I found a better way to reproduce and observe this.

1. The issue can be seen even without the sqlite update.

Run 'bitbake gcc-runtime', then delete tmp/ then run 'bitbake -c
package gcc-runtime'.

Then take a look at tmp/log/cooker/qemux86-64/console-latest.log, and
it should have:

NOTE: Executing Tasks
NOTE: Running setscene task 1 of 304
(virtual:native:/srv/work/alex/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot_setscene)
NOTE: recipe pseudo-native-1.9.2+git-r0: task
do_populate_sysroot_setscene: Started
NOTE: recipe pseudo-native-1.9.2+git-r0: task
do_populate_sysroot_setscene: Succeeded
NOTE: Running setscene task 2 of 304
(/srv/work/alex/poky/meta/recipes-devtools/gcc/gcc-runtime_15.2.bb:do_package_setscene)
NOTE: Running setscene task 4 of 304
(virtual:native:/srv/work/alex/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_recipe_qa_setscene)
NOTE: recipe pseudo-native-1.9.2+git-r0: task do_recipe_qa_setscene: Started
NOTE: recipe gcc-runtime-15.2.0-r0: task do_package_setscene: Started

Which means, pseudo is installed, but not sqlite. Then tasks that
depend on pseudo start running, and they seem to work by happy
coincidence (fall-through to host sqlite).

2. With the sqlite update, that fall-through breaks (with the same
command sequnce):

NOTE: Executing Tasks
NOTE: Running setscene task 1 of 304
(virtual:native:/srv/work/alex/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot_setscene)
NOTE: recipe pseudo-native-1.9.2+git-r0: task
do_populate_sysroot_setscene: Started
NOTE: recipe pseudo-native-1.9.2+git-r0: task
do_populate_sysroot_setscene: Succeeded
NOTE: Running setscene task 3 of 304
(virtual:native:/srv/work/alex/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_recipe_qa_setscene)
NOTE: Running setscene task 4 of 304
(/srv/work/alex/poky/meta/recipes-devtools/gcc/gcc-runtime_15.2.bb:do_package_setscene)
ERROR: An uncaught exception occurred in runqueue
Traceback (most recent call last):
  File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1661, in
execute_runqueue
    return self._execute_runqueue()
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1627, in
_execute_runqueue
    retval = self.rqexe.execute()
             ^^^^^^^^^^^^^^^^^^^^
  File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 2317, in execute
    self.rq.start_fakeworker(self, mc)
  File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1437, in
start_fakeworker
    self.fakeworker[mc] = self._start_worker(mc, True, rqexec)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1406, in
_start_worker
    RunQueue.send_pickled_data(worker, workerdata, "workerdata")
  File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1365, in
send_pickled_data
    worker.stdin.write(msg)
BrokenPipeError: [Errno 32] Broken pipe


3. I don't yet know how to solve this either. This will work, but
hardcodes pseudo's particular dependencies into a location which
refers only to a generic fakeroot implementation:

diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
...
-        d.appendVarFlag('do_package_setscene', 'depends', '
virtual/fakeroot-native:do_populate_sysroot')
+        d.appendVarFlag('do_package_setscene', 'depends', '
virtual/fakeroot-native:do_populate_sysroot
sqlite3-native:do_populate_sysroot')
...

I'm afraid, RP needs to step in :-/

Alex

RE: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Marko, Peter]

I have sent a new version with soname=legacy which links against .0.
So the update should hopefully finally work now.

But of course, the setscene behavior is still something which should be
analyzed. Maybe bugzilla ticket should be raised to not forget about it.

Peter

> -----Original Message-----
> From: Alexander Kanavin <alex.kanavin@gmail.com>
> Sent: Monday, September 1, 2025 14:07
> To: alex.kanavin@gmail.com
> Cc: skandigraun@gmail.com; Marko, Peter (FT D EU SK BFS1)
> <Peter.Marko@siemens.com>; gudni.m.g@gmail.com; openembedded-
> core@lists.openembedded.org; Richard Purdie
> <richard.purdie@linuxfoundation.org>
> Subject: Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2
> 
> On Mon, 1 Sept 2025 at 13:15, Alexander Kanavin via
> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
> wrote:
> > That said, non-deterministically falling through to the host libsqlite
> > is wrong as well, it just wasn't previously exposed. We need to figure
> > out this one first, and fix it properly, and only then address the
> > pseudo linking issue above.
> 
> I found a better way to reproduce and observe this.
> 
> 1. The issue can be seen even without the sqlite update.
> 
> Run 'bitbake gcc-runtime', then delete tmp/ then run 'bitbake -c
> package gcc-runtime'.
> 
> Then take a look at tmp/log/cooker/qemux86-64/console-latest.log, and
> it should have:
> 
> NOTE: Executing Tasks
> NOTE: Running setscene task 1 of 304
> (virtual:native:/srv/work/alex/poky/meta/recipes-
> devtools/pseudo/pseudo_git.bb:do_populate_sysroot_setscene)
> NOTE: recipe pseudo-native-1.9.2+git-r0: task
> do_populate_sysroot_setscene: Started
> NOTE: recipe pseudo-native-1.9.2+git-r0: task
> do_populate_sysroot_setscene: Succeeded
> NOTE: Running setscene task 2 of 304
> (/srv/work/alex/poky/meta/recipes-devtools/gcc/gcc-
> runtime_15.2.bb:do_package_setscene)
> NOTE: Running setscene task 4 of 304
> (virtual:native:/srv/work/alex/poky/meta/recipes-
> devtools/pseudo/pseudo_git.bb:do_recipe_qa_setscene)
> NOTE: recipe pseudo-native-1.9.2+git-r0: task do_recipe_qa_setscene: Started
> NOTE: recipe gcc-runtime-15.2.0-r0: task do_package_setscene: Started
> 
> Which means, pseudo is installed, but not sqlite. Then tasks that
> depend on pseudo start running, and they seem to work by happy
> coincidence (fall-through to host sqlite).
> 
> 2. With the sqlite update, that fall-through breaks (with the same
> command sequnce):
> 
> NOTE: Executing Tasks
> NOTE: Running setscene task 1 of 304
> (virtual:native:/srv/work/alex/poky/meta/recipes-
> devtools/pseudo/pseudo_git.bb:do_populate_sysroot_setscene)
> NOTE: recipe pseudo-native-1.9.2+git-r0: task
> do_populate_sysroot_setscene: Started
> NOTE: recipe pseudo-native-1.9.2+git-r0: task
> do_populate_sysroot_setscene: Succeeded
> NOTE: Running setscene task 3 of 304
> (virtual:native:/srv/work/alex/poky/meta/recipes-
> devtools/pseudo/pseudo_git.bb:do_recipe_qa_setscene)
> NOTE: Running setscene task 4 of 304
> (/srv/work/alex/poky/meta/recipes-devtools/gcc/gcc-
> runtime_15.2.bb:do_package_setscene)
> ERROR: An uncaught exception occurred in runqueue
> Traceback (most recent call last):
>   File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1661, in
> execute_runqueue
>     return self._execute_runqueue()
>            ^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1627, in
> _execute_runqueue
>     retval = self.rqexe.execute()
>              ^^^^^^^^^^^^^^^^^^^^
>   File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 2317, in execute
>     self.rq.start_fakeworker(self, mc)
>   File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1437, in
> start_fakeworker
>     self.fakeworker[mc] = self._start_worker(mc, True, rqexec)
>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1406, in
> _start_worker
>     RunQueue.send_pickled_data(worker, workerdata, "workerdata")
>   File "/srv/work/alex/poky/bitbake/lib/bb/runqueue.py", line 1365, in
> send_pickled_data
>     worker.stdin.write(msg)
> BrokenPipeError: [Errno 32] Broken pipe
> 
> 
> 3. I don't yet know how to solve this either. This will work, but
> hardcodes pseudo's particular dependencies into a location which
> refers only to a generic fakeroot implementation:
> 
> diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
> ...
> -        d.appendVarFlag('do_package_setscene', 'depends', '
> virtual/fakeroot-native:do_populate_sysroot')
> +        d.appendVarFlag('do_package_setscene', 'depends', '
> virtual/fakeroot-native:do_populate_sysroot
> sqlite3-native:do_populate_sysroot')
> ...
> 
> I'm afraid, RP needs to step in :-/
> 
> Alex

Re: [OE-core] [PATCH] sqlite3: upgrade 3.48.0 -> 3.50.2

[Alexander Kanavin]

On Thu, 4 Sept 2025 at 00:31, Marko, Peter <Peter.Marko@siemens.com> wrote:
>
> I have sent a new version with soname=legacy which links against .0.
> So the update should hopefully finally work now.
>
> But of course, the setscene behavior is still something which should be
> analyzed. Maybe bugzilla ticket should be raised to not forget about it.

Filed here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15963

Alex