[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hurd: Add multilib paths for gnu-x86_64

From: rep . dot . nop
Subject: Re: hurd: Add multilib paths for gnu-x86_64
Date: Thu, 30 Nov 2023 07:44:51 +0100

On 27 November 2023 15:48:33 CET, Thomas Schwinge <thomas@codesourcery.com> 
>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.
>> 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]