gcc: Fix riscv multilib issues in plain toolchains

RISC-V multilib currently doesn't work at all. We could disable multilib for
the riscv platform but that would then behave differently to all our others.
Instead, copy the non-multilib config over the multilib config for now for
riscv, meaning we can keep the platforms similar.

This isn't quite enough as the triplet specific c++ headers are in the wrong
place leading to compiler issues and testimage failures. Work around that too
until someone adds full multilib support for the platform (if desired).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/recipes-devtools/gcc/gcc-multilib-config.inc | 6 ++++++
 meta/recipes-devtools/gcc/gcc-runtime.inc         | 5 +++++
 2 files changed, 11 insertions(+)

On Wed, May 14, 2025 at 8:17 AM Richard Purdie via
lists.openembedded.org
<richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
>
> RISC-V multilib currently doesn't work at all. We could disable multilib for
> the riscv platform but that would then behave differently to all our others.
> Instead, copy the non-multilib config over the multilib config for now for
> riscv, meaning we can keep the platforms similar.
>
> This isn't quite enough as the triplet specific c++ headers are in the wrong
> place leading to compiler issues and testimage failures. Work around that too
> until someone adds full multilib support for the platform (if desired).
>

This is in-line with what we have done so far so I am good that way.
The multilib mapping
makes me nervous though, it just keeps growing and it might not be
sufficient for bare metal
multilib cases. I think we need some re-doing to accommodate it.

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/recipes-devtools/gcc/gcc-multilib-config.inc | 6 ++++++
>  meta/recipes-devtools/gcc/gcc-runtime.inc         | 5 +++++
>  2 files changed, 11 insertions(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-multilib-config.inc b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
> index 2dbbc23c940..d9959364c3a 100644
> --- a/meta/recipes-devtools/gcc/gcc-multilib-config.inc
> +++ b/meta/recipes-devtools/gcc/gcc-multilib-config.inc
> @@ -34,6 +34,7 @@ python gcc_multilib_setup() {
>                  '%s/aarch64/aarch64-linux.h' % src_conf_dir,
>                  '%s/aarch64/aarch64-cores.def' % src_conf_dir,
>                  '%s/arm/linux-eabi.h' % src_conf_dir,
> +                '%s/riscv/t-linux*' % src_conf_dir,
>                  '%s/*/linux.h' % src_conf_dir,
>                  '%s/linux.h' % src_conf_dir)
>
> @@ -45,6 +46,9 @@ python gcc_multilib_setup() {
>              bb.utils.mkdirhier('%s/%s' % (build_conf_dir, parent_dir))
>              bb.utils.copyfile(fn, '%s/%s' % (build_conf_dir, rel_path))
>
> +    # For now, force the riscv multilib view to our own meaning we can always enable multilib
> +    bb.utils.copyfile('%s/riscv/t-linux' % src_conf_dir, '%s/riscv/t-linux-multilib' % build_conf_dir)
> +
>      pn = d.getVar('PN')
>      multilibs = (d.getVar('MULTILIB_VARIANTS') or '').split()
>      if not multilibs and pn != "nativesdk-gcc":
> @@ -145,6 +149,7 @@ python gcc_multilib_setup() {
>          'i686'      : ['gcc/config/i386/t-linux64'],
>          'mips'      : ['gcc/config/mips/t-linux64'],
>          'mips64'    : ['gcc/config/mips/t-linux64'],
> +        'riscv64'     : ['gcc/config/riscv/t-linux-multilib'],
>          'powerpc'   : ['gcc/config/rs6000/t-linux64'],
>          'powerpc64' : ['gcc/config/rs6000/t-linux64'],
>          'aarch64'   : ['gcc/config/aarch64/t-aarch64'],
> @@ -161,6 +166,7 @@ python gcc_multilib_setup() {
>          'powerpc64' : ['gcc/config/linux.h', 'gcc/config/rs6000/linux64.h'],
>          'aarch64'   : ['gcc/config/linux.h', 'gcc/config/aarch64/aarch64-linux.h', 'gcc/config/arm/linux-eabi.h'],
>          'arm'       : ['gcc/config/linux.h', 'gcc/config/aarch64/aarch64-linux.h', 'gcc/config/arm/linux-eabi.h'],
> +        'riscv64'     : ['gcc/config/linux.h'],
>      }
>
>      libdir32 = 'SYSTEMLIBS_DIR'
> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc
> index afcc13a310c..fe1f43b2fd7 100644
> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> @@ -144,6 +144,11 @@ do_install:append:class-target () {
>                 ln -sf ../${X86ARCH32}${TARGET_VENDOR}-${TARGET_OS} ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-${TARGET_OS}/32
>         fi
>
> +       if [ "${TARGET_ARCH}" = "riscv64" -a "${MULTILIB_VARIANTS}" = "" ]; then
> +               mv ${D}${includedir}/c++/${BINV}/${TARGET_SYS}/bits/* ${D}${includedir}/c++/${BINV}/bits
> +               mv ${D}${includedir}/c++/${BINV}/${TARGET_SYS}/ext/* ${D}${includedir}/c++/${BINV}/ext
> +       fi
> +
>         if [ "${TCLIBC}" != "glibc" ]; then
>                 case "${TARGET_OS}" in
>                         "linux-musl" | "linux-*spe") extra_target_os="linux";;
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#216497): https://lists.openembedded.org/g/openembedded-core/message/216497
> Mute This Topic: https://lists.openembedded.org/mt/113110028/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On Wed, 2025-05-14 at 08:32 -0700, Khem Raj wrote:
> On Wed, May 14, 2025 at 8:17 AM Richard Purdie via
> lists.openembedded.org
> <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> > 
> > RISC-V multilib currently doesn't work at all. We could disable multilib for
> > the riscv platform but that would then behave differently to all our others.
> > Instead, copy the non-multilib config over the multilib config for now for
> > riscv, meaning we can keep the platforms similar.
> > 
> > This isn't quite enough as the triplet specific c++ headers are in the wrong
> > place leading to compiler issues and testimage failures. Work around that too
> > until someone adds full multilib support for the platform (if desired).
> > 
> 
> This is in-line with what we have done so far so I am good that way.
> The multilib mapping
> makes me nervous though, it just keeps growing and it might not be
> sufficient for bare metal
> multilib cases. I think we need some re-doing to accommodate it.

Agreed, this will need further work but it at least puts things in line
with what we have already. The multilib code could probably do with
rethinking in general. The c++ header changes in the gcc-runtime recipe
are depressing.

Cheers,

Richard