Hello,
Thomas Schwinge, le lun. 27 nov. 2023 15:48:33 +0100, a ecrit:
> On 2023-10-28T21:19:59+0200, Samuel Thibault <samuel.thiba...@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
