| Message ID | 20241113125147.4193489-1-Deepthi.Hemraj@windriver.com |
|---|---|
| State | New |
| Headers | show |
| Series | gcc-target.inc: Fix gcc symlink handling for multilib support | expand |
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
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
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
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