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:*[email protected]
>>> <[email protected]> *On Behalf Of *Guðni Már
>>> Gilbert via lists.openembedded.org
>>> *Sent:* Saturday, July 12, 2025 16:12
>>> *To:* [email protected]
>>> *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 (#222655):
https://lists.openembedded.org/g/openembedded-core/message/222655
Mute This Topic: https://lists.openembedded.org/mt/114116736/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
