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

Andrej Valek andrej.valek at siemens.com
Tue Apr 30 10:41:09 UTC 2019


Hi Richard,

On 4/30/19 12:26 PM, Richard Purdie wrote:
> 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.
> 
It was a test, to get list of packages, which could have a problem.

> 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?
> 
Yes, this is working well. But Let say, python modules are installed on
the different location for 64-bit (/usr/lib/python) and 32-bit
(/usr/lib32/python3.5). Each python version is searching for modules on
certain path. So linker don't know about this behavior, because it's
handled by python itself.
Maybe we can extend the "PYTHONPATH" to search also for modules in
another path. But I am not sure about the 64/32 bit module compatibility.

> What am I missing? Is something not working like that? Is this with the
> rpm or opkg implementation? (they're very different)
> 
I have tested it via opkg. Is it somehow "fixed" in rpm?
> Cheers,
> 
> Richard
> 

Regards,

Andrej


More information about the Openembedded-core mailing list