Re: hurd: Add multilib paths for gnu-x86_64

[rep . dot . nop]

On 27 November 2023 15:48:33 CET, Thomas Schwinge <thomas@codesourcery.com> 
wrote:
>Hi!
>
>On 2023-10-28T21:19:59+0200, Samuel Thibault <samuel.thibault@gnu.org> wrote:
>> We need the multilib paths in gcc to find e.g. glibc crt files on
>> Debian.
>
>ACK.
>
>> This is essentially based on t-linux64 version.
>
>Yes, but isn't the overall setup diverged from GNU/Linux?
>
>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'.  Instead, I
>suppose, we should handle 'i386/t-linux64' and 'i386/t-gnu64' alike, and
>resolve relevant configuration differences.
>
>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?
>
>However, such things can certainly be resolved incrementally, later on.
>I understand that your change does work for you as-is, so I've now pushed
>that to master branch in commit 5707e9db9c398d311defc80c5b7822c9a07ead60
>"hurd: Add multilib paths for gnu-x86_64", see attached.

+# To support i386, x86-64 and x32 libraries, the directory structrue

I guess one could legitimately understand this as a "structure setting 
standards " ;) but let's spell it structure nevertheless?

cheers