Re: [OE-core] [PATCH] gcc-target.inc: Fix gcc symlink handling for multilib support

[Randy MacLeod <randy.macleod@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 4816 bytes --]

Summary:

Deepthi:
   to check if adding  bcc, bpftrace to meta-clang's 
NON_MULTILIB_RECIPES list avoids the error and

Richard and others:
   to comment on if that makes sense.

More below.

On 2024-11-13 8:23 a.m., Richard Purdie wrote:
> On Wed, 2024-11-13 at 04:51 -0800, Hemraj, Deepthi via lists.openembedded.org wrote:
>> From: Deepthi Hemraj<Deepthi.Hemraj@windriver.com>
>>
>> Enabling multilib support and adding both lib32-gcc-symlinks and gcc-symlinks
>> to the image installation results in a conflict between
>> gcc-symlinks-13.3.0-r0.corei7_64 and lib32-gcc-symlinks-13.3.0-r0.corei7_32.
>> Following error occurs because of the conflict:
>> "file /usr/bin/gcc conflicts between attempted installs of gcc-symlinks-13.3.0-r0.corei7_64 and lib32-gcc-symlinks-13.3.0-r0.corei7_32"
>>
>> The conflict occurs because both packages try to install files in the same location,
>> causing installation errors during the build process.
>>
>> Updated the gcc target recipe to correctly handle symlinks for multilib support by using ${MLPREFIX}gcc
>> instead of just gcc for the gcc binary symlink in ${PN}-symlinks.
>> This ensures that the symlinks point to the appropriate multilib gcc binary for 32-bit and 64-bit configurations.
>>
>> Signed-off-by: Deepthi Hemraj<Deepthi.Hemraj@windriver.com>
>> ---
>>   meta/recipes-devtools/gcc/gcc-target.inc | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-target.inc b/meta/recipes-devtools/gcc/gcc-target.inc
>> index 6b47c10413..ff59eb1b52 100644
>> --- a/meta/recipes-devtools/gcc/gcc-target.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-target.inc
>> @@ -71,7 +71,7 @@ FILES:${PN}-dev = "\
>>   "
>>   FILES:${PN}-symlinks = "\
>>       ${bindir}/cc \
>> -    ${bindir}/gcc \
>> +    ${bindir}/${MLPREFIX}gcc \
>>       ${bindir}/gccbug \
>>   "
>>   
>> @@ -182,7 +182,7 @@ do_install () {
>>   		ln -sf gfortran f95 || true
>>   	fi
>>   	ln -sf ${TARGET_PREFIX}g++ g++
>> -	ln -sf ${TARGET_PREFIX}gcc gcc
>> +	ln -sf ${TARGET_PREFIX}gcc ${MLPREFIX}gcc
>>   	ln -sf ${TARGET_PREFIX}cpp cpp
>>   	ln -sf ${TARGET_PREFIX}gcov gcov
>>   	ln -sf ${TARGET_PREFIX}gcov-tool gcov-tool
>>
> No, sorry, but definitely not.
>
> You can install one of these or the other but both doesn't make any
> sense, just don't do that.

I agree that one should avoid this if possible.

In our WR Linux bug description, the issue seems to be that:
if you have a 64 bit kernel, and a 32 bit userspace image and you add:
    IMAGE_INSTALL:append = " bpftrace"
in conf/local.conf then the error occurs.

You can't use lib32-bpftrace since that's not supported apparently:
    COMPATIBLE_HOST = "(x86_64.*|aarch64.*|powerpc64.*|riscv64.*)-linux"
From:
https://github.com/kraj/meta-clang/commit/952f28c59439a146032b14260d5f6ad69d83426e
and for bcc, that's done, without explanation in the commit log, in:
https://github.com/kraj/meta-clang/commit/93511705


By the way, this isn't a urgent, or critical use case.
It was just found in testing and seems like it's worth trying to get to 
the root cause.


Deepthi,

Please confirm that you are able to reproduce the issue using just poky 
and meta-clang.
I want to be sure that this is not a bug in WR Linux.

Also, does the issue go away if you add bcc, bpftrace to 
NON_MULTILIB_RECIPES in the meta-clang layer? see 1), below.


>
> I also don't understand how this fixes things since surely all the
> other symlinks conflict too?

Yes!

We'll have to see if we actually care about lib32-gcc-symlinks.

The only use case that I can see is to be able to easily install both 32 
and 64 bit toolchains, symlinks
on target to be able to build say a kernel module and a userspace 
package for self-hosted
development.

../Randy



1) Some info (from scarhtgap) on NON_MULTILIB_RECIPES

poky.git on scarthgap
✦ ❯ rg NON_MULTILIB_RECIPES
meta/classes/multilib.bbclass
20:    non_ml_recipes = d.getVar('NON_MULTILIB_RECIPES').split()
33:    # We nearly don't need this but dependencies on 
NON_MULTILIB_RECIPES don't work without it

meta/classes/multilib_global.bbclass
187:    non_ml_recipes = d.getVar('NON_MULTILIB_RECIPES').split()

documentation/ref-manual/variables.rst
5606:   :term:`NON_MULTILIB_RECIPES`
5611:         NON_MULTILIB_RECIPES = "grub grub-efi make-mod-scripts 
ovmf u-boot"

meta/conf/multilib.conf
27:NON_MULTILIB_RECIPES = "grub grub-efi make-mod-scripts ovmf u-boot"


meta-clang.git on master
✦ ❯ rg NON_MULTILIB_RECIPES
conf/layer.conf
38:NON_MULTILIB_RECIPES:append = " llvm-project-source"

> Cheers,
>
> Richard


-- 
# Randy MacLeod
# Wind River Linux

[-- Attachment #2: Type: text/html, Size: 7240 bytes --]