* [PATCH,resend] hurd: Add multilib paths for gnu-x86_64
@ 2023-10-28 19:19 Samuel Thibault
2023-11-27 14:48 ` Thomas Schwinge
0 siblings, 1 reply; 4+ messages in thread
From: Samuel Thibault @ 2023-10-28 19:19 UTC (permalink / raw)
To: gcc-patches, Thomas Schwinge; +Cc: bug-hurd
We need the multilib paths in gcc to find e.g. glibc crt files on
Debian. This is essentially based on t-linux64 version.
gcc/ChangeLog:
* gcc/config/i386/t-gnu64: New file.
* gcc/config.gcc [x86_64-*-gnu*): Add i386/t-gnu64 to
tmake_file.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 671c7e3b018..6b1939b9f09 100644
--- 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
t=
diff --git a/gcc/config/i386/t-gnu64 b/gcc/config/i386/t-gnu64
index e69de29bb2d..23ee6823d65 100644
--- a/gcc/config/i386/t-gnu64
+++ b/gcc/config/i386/t-gnu64
@@ -0,0 +1,38 @@
+# Copyright (C) 2002-2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# <http://www.gnu.org/licenses/>.
+
+# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
+# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
+# /lib and /usr/lib, while other distributions install libraries into /lib64
+# and /usr/lib64. The LSB does not enforce the use of /lib64 and /usr/lib64,
+# it doesn't tell anything about the 32bit libraries on those systems. Set
+# MULTILIB_OSDIRNAMES according to what is found on the target.
+
+# To support i386, x86-64 and x32 libraries, the directory structrue
+# should be:
+#
+# /lib has i386 libraries.
+# /lib64 has x86-64 libraries.
+# /libx32 has x32 libraries.
+#
+comma=,
+MULTILIB_OPTIONS = $(subst $(comma),/,$(TM_MULTILIB_CONFIG))
+MULTILIB_DIRNAMES = $(patsubst m%, %, $(subst /, ,$(MULTILIB_OPTIONS)))
+MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-gnu)
+MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:i386-gnu)
+MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-gnux32)
^ permalink raw reply [flat|nested] 4+ messages in thread
* hurd: Add multilib paths for gnu-x86_64
2023-10-28 19:19 [PATCH,resend] hurd: Add multilib paths for gnu-x86_64 Samuel Thibault
@ 2023-11-27 14:48 ` Thomas Schwinge
2023-11-27 19:11 ` Samuel Thibault
2023-11-30 6:44 ` rep.dot.nop
0 siblings, 2 replies; 4+ messages in thread
From: Thomas Schwinge @ 2023-11-27 14:48 UTC (permalink / raw)
To: Samuel Thibault, gcc-patches; +Cc: bug-hurd
[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]
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.
Grüße
Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-hurd-Add-multilib-paths-for-gnu-x86_64.patch --]
[-- Type: text/x-diff, Size: 2928 bytes --]
From 5707e9db9c398d311defc80c5b7822c9a07ead60 Mon Sep 17 00:00:00 2001
From: Samuel Thibault <samuel.thibault@gnu.org>
Date: Sat, 6 May 2023 13:50:36 +0200
Subject: [PATCH] hurd: Add multilib paths for gnu-x86_64
We need the multilib paths in gcc to find e.g. glibc crt files on
Debian. This is essentially based on t-linux64 version.
gcc/ChangeLog:
* config/i386/t-gnu64: New file.
* config.gcc [x86_64-*-gnu*]: Add i386/t-gnu64 to
tmake_file.
---
gcc/config.gcc | 3 +++
gcc/config/i386/t-gnu64 | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 41 insertions(+)
create mode 100644 gcc/config/i386/t-gnu64
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 3000379cafc..e62849c1230 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -5973,6 +5973,9 @@ case ${target} in
visium-*-*)
target_cpu_default2="TARGET_CPU_$with_cpu"
;;
+ x86_64-*-gnu*)
+ tmake_file="$tmake_file i386/t-gnu64"
+ ;;
esac
t=
diff --git a/gcc/config/i386/t-gnu64 b/gcc/config/i386/t-gnu64
new file mode 100644
index 00000000000..23ee6823d65
--- /dev/null
+++ b/gcc/config/i386/t-gnu64
@@ -0,0 +1,38 @@
+# Copyright (C) 2002-2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3. If not see
+# <http://www.gnu.org/licenses/>.
+
+# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
+# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
+# /lib and /usr/lib, while other distributions install libraries into /lib64
+# and /usr/lib64. The LSB does not enforce the use of /lib64 and /usr/lib64,
+# it doesn't tell anything about the 32bit libraries on those systems. Set
+# MULTILIB_OSDIRNAMES according to what is found on the target.
+
+# To support i386, x86-64 and x32 libraries, the directory structrue
+# should be:
+#
+# /lib has i386 libraries.
+# /lib64 has x86-64 libraries.
+# /libx32 has x32 libraries.
+#
+comma=,
+MULTILIB_OPTIONS = $(subst $(comma),/,$(TM_MULTILIB_CONFIG))
+MULTILIB_DIRNAMES = $(patsubst m%, %, $(subst /, ,$(MULTILIB_OPTIONS)))
+MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-gnu)
+MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:i386-gnu)
+MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-gnux32)
--
2.34.1
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: hurd: Add multilib paths for gnu-x86_64
2023-11-27 14:48 ` Thomas Schwinge
@ 2023-11-27 19:11 ` Samuel Thibault
2023-11-30 6:44 ` rep.dot.nop
1 sibling, 0 replies; 4+ messages in thread
From: Samuel Thibault @ 2023-11-27 19:11 UTC (permalink / raw)
To: Thomas Schwinge; +Cc: gcc-patches, bug-hurd
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: hurd: Add multilib paths for gnu-x86_64
2023-11-27 14:48 ` Thomas Schwinge
2023-11-27 19:11 ` Samuel Thibault
@ 2023-11-30 6:44 ` rep.dot.nop
1 sibling, 0 replies; 4+ messages in thread
From: rep.dot.nop @ 2023-11-30 6:44 UTC (permalink / raw)
To: gcc-patches, Thomas Schwinge, Samuel Thibault; +Cc: bug-hurd
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-11-30 6:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-28 19:19 [PATCH,resend] hurd: Add multilib paths for gnu-x86_64 Samuel Thibault
2023-11-27 14:48 ` Thomas Schwinge
2023-11-27 19:11 ` Samuel Thibault
2023-11-30 6:44 ` rep.dot.nop
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).