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. The sstate oe-selftest do operations much like this already so more automated tests wouldn't be hard either. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2041): https://lists.openembedded.org/g/openembedded-architecture/message/2041 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]] -=-=-=-=-=-=-=-=-=-=-=-
