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

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

[Deepthi.Hemraj]

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
-- 
2.43.0

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

[Richard Purdie]

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 also don't understand how this fixes things since surely all the
other symlinks conflict too?

Cheers,

Richard

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

[Randy MacLeod]

[-- 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 --]

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

[Richard Purdie]

On Wed, 2024-11-13 at 14:58 -0500, Randy MacLeod wrote:
>  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.

With these kinds of issues you need to take a step back and think about
what is going on.

gcc is parallel installable since the 32 and 64 bit triplets are
different. The gcc-symlinks package provides a mapping of "gcc" to one
of them. If you rename "gcc" to "${MLPREFIX}gcc" it won't help anything
since the software is still looking for "gcc" if it depends on gcc-
symlinks.

You could make the software using "gcc" use the full name instead and
skip gcc-symlinks. You could realise it doesn't matter and make both
the 32 and 64 bit versions use "gcc" and skip the lib32-gcc-symlinks.

I don't see a scenario where lib32-gcc-symlinks being installed at the
same time as gcc-symlinks makes sense though. If you rename the
symlink, nothing is going to use it, it just hacks around the conflict.

I have said several times that just throwing a MLPREFIX in front of
things is sometimes *not* the right solution and that you need to keep
the big picture in mind and how this fits into it.



> 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.
>  

gcc and lib32-gcc can be installed together ok as far as I know. The
symlinks package is what links "gcc" to the triplet gcc and you can
only have one of them. Which is why I'm pushing back on this patch.

Cheers,

Richard