[OE-core] [PATCH 0/1] insane.bbclass: Add QA package check for mixed bins and libs

Richard Purdie richard.purdie at linuxfoundation.org
Tue Apr 30 10:26:54 UTC 2019


On Tue, 2019-04-30 at 11:59 +0200, Andrej Valek wrote:
> In multi-lib cases some packages with mixed binaries and libraries
> could have a problem. Explanations with GDB and bmap-tools.
> 
> GDB requires python binary (RDEPENDS) and bmap-tools too.
> GDB is installed as 32bit variant and bmap-tools as 64bit.
> In the current state both type (32+64) of required libraries
> will be installed on the target. (I think' this is the right case.)
> 
> At the end a 32bit variant of binaries wins and overrides the 64bit.
> Finally GDB is working without any problems and bmap-tools not.
> Bacuse 64-bit python binary was overriden with 32-bit.
> 
> All-arch variant has been disabled for multilib. Is there any special
> reson why?

Yes, this had long discussion and was done very reluctantly.

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d9ba0219b2f6643ffc825d4b8d3494d07237dd0b

was the commit but there was a lot of discussion on the list before it
merged.

> How we can proceed with this kind of problem? There are many others
> tools like python, perl, ... . 
> 
> Just for info, I have run this check locally with current
> `bitbake world`, >100 packages have this problem.

Merging a QA test which causes hundreds of warnings isn't really going
to help unless we have a strategy for fixing it.

As I understand it, if you install python 32bit and 64 bit, you should
get the libraries from both but only the binaries from the one that
wins. That should mean anything linking to the lib should work?

What am I missing? Is something not working like that? Is this with the
rpm or opkg implementation? (they're very different)

Cheers,

Richard





More information about the Openembedded-core mailing list