Re: hurd: Add multilib paths for gnu-x86_64

[Samuel Thibault]

Hello,

Thomas Schwinge, le lun. 27 nov. 2023 15:48:33 +0100, a ecrit:
> On 2023-10-28T21:19:59+0200, Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > This is essentially based on t-linux64 version.
> 
> Yes, but isn't the overall setup diverged from GNU/Linux?

Not sure what you mean exactly?
I just meant that the content of t-gnu64 is almost the same as
t-linux64, the only difference being the multiarch path.

> Currently, x86_64 GNU/Hurd first gets 'i386/t-linux64', whose definitons
> are only later:
> 
> > --- a/gcc/config.gcc
> > +++ b/gcc/config.gcc
> > @@ -5828,6 +5828,9 @@ case ${target} in
> >       visium-*-*)
> >               target_cpu_default2="TARGET_CPU_$with_cpu"
> >               ;;
> > +     x86_64-*-gnu*)
> > +             tmake_file="$tmake_file i386/t-gnu64"
> > +             ;;
> >  esac
> 
> ... then here (effectively) overwritten by 'i386/t-gnu64'.

Yes, like it is done for the x86_64-*-freebsd*) case

> Instead, I suppose, we should handle 'i386/t-linux64' and
> 'i386/t-gnu64' alike, and resolve relevant configuration differences.

So essentially move 

tmake_file="${tmake_file} i386/t-linux64"

down from where it is currently, to the 

# Set some miscellaneous flags for particular targets.
target_cpu_default2=
case ${target} in

part? That should be fine for kfreebsd as well.

> As fas a I can tell, 'i386/t-linux64' is also used for multilib-enabled
> ('test x$enable_targets = xall') x86 GNU/Linux, and that's not
> (correspondingly) done for x86 GNU/Hurd?

We don't really plan to support 32/64 multilib support in GNU/Hurd.

> However, such things can certainly be resolved incrementally, later on.
> I understand that your change does work for you as-is,

Thanks for your understanding :) that'll help pushing further in Debian.

Samuel