On Wed, Sep 04, 2024 at 05:04:50PM +0100, Richard Purdie wrote:
> On Wed, 2024-09-04 at 11:30 -0400, Denys Dmytriyenko wrote:
> > FWIW, that's what I ended up doing back then, instead of relying on the
> > distros to set TCLIBCAPPEND correctly:
> >
> > https://git.yoctoproject.org/meta-ti/commit/?id=488a9238140661dce8510694a05dd04ff023855d
> >
> > So, I guess if we decide to globally drop TCLIBCAPPEND from OE-Core, at
> > least this particular issue in meta-ti is already covered...
> >
> > Right now OE-Core "nodistro" enables TMPDIR separation by TCLIBC, while
> > Poky forces a combined TMPDIR. All tests on the Autobuilder are performed
> > with Poky, hence the separate TMPDIR isn't being tested. And you mentioned
> > that one of the multiconfig selftests is indeed broken with such setup.
> >
> > I'm just concerned that aligning OE-Core with Poky and defaulting to a
> > combined TMPDIR will further push such setups out to a fringe status,
> > never to be tested or fixed, if something breaks. Or maybe I'm just too
> > paranoid... :)
>
> I'm not sure anyone is actually using it, there is a simple alternative
> way to achieve the same result and we all agree we should improve the
> different libcs behaviour which can happen even if it is removed.
>
> It is really easy to test if there are conflicts. In a clean TMPDIR, I
> used:
>
> bitbake hicolor-icon-theme bash -S none
>
> then set TCLIBC=musl and ran it again. I then checked for diverging
> sigdata files in the stamps directory (you could capture the list of
> files before/after the second bitbake command).
>
> You then repeat this for each TCLIBC you want to test. If there aren't
> overlapping sigs, the configurations are single TMPDIR safe.
What happens when those are built at the same time? E.g. set multiconfigs
per TCLIBC and add dependency on both:
do_image[mcdepends] += "mc::glibc:bash:do_build mc::musl:bash:do_build"
I just tried something like that and it hits some weird races trying to
build native packages of basic tools for both MCs...
Like zstd-native:
|
.../build/tmp/work/x86_64-linux/zstd-native/1.5.6/git/lib//compress/zstd_lazy.c:2198:1:
fatal error: opening dependency file
obj/conf_912075445e7510d156c0bcf8c4999c47/static/zstd_lazy.d: No such file or
directory
Or bison-native:
ERROR: bison-native-3.8.2-r0 do_prepare_recipe_sysroot: The sstate manifest for
task 'libtool-native:populate_sysroot' (multilib variant '') could not be found.
The pkgarchs considered were: x86_64, x86_64_ubuntu-22.04.
But none of these manifests exists:
.../build/tmp/sstate-control/manifest-x86_64-libtool-native.populate_sysroot
.../build/tmp/sstate-control/manifest-x86_64_ubuntu-22.04-libtool-native.populate_sysroot
ERROR: Logfile of failure stored in:
.../build/tmp/work/x86_64-linux/bison-native/3.8.2/temp/log.do_prepare_recipe_sysroot.224317
ERROR: Task
(virtual:native:.../meta/recipes-devtools/bison/bison_3.8.2.bb:do_prepare_recipe_sysroot)
failed with exit code '1'
Or m4-native:
| cd .. && make am--refresh
| shell-init: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
| chdir: error retrieving current directory: getcwd: cannot access parent
directories: No such file or directory
| make: getcwd: No such file or directory
This all looks similar to what I originally reported in that bugzilla entry
from last November...
What about bitbake's ability to defer identical/dependent tasks and print
"Deferring %s after %s" and "Deferred task %s now buildable"?
IIRC, this used to happen when multiple multiconfigs depend on the same
component, so bitbake would build such dependency in one MC and defer the
other MCs until that's ready.
> The sstate oe-selftest do operations much like this already so more
> automated tests wouldn't be hard either.
--
Denys
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2042):
https://lists.openembedded.org/g/openembedded-architecture/message/2042
Mute This Topic: https://lists.openembedded.org/mt/108262278/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
