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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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