Re: [patch] support for multiarch systems

[Thomas Schwinge]

Hi!

On Thu, 28 Jun 2012 12:42:23 +0200, Matthias Klose  wrote:
> On 28.06.2012 12:01, Thomas Schwinge wrote:
> > On Mon, 25 Jun 2012 18:19:26 +0200, Matthias Klose 
> > wrote:
> >> On 25.06.2012 15:56, Joseph S. Myers wrote:
> >>> On Mon, 25 Jun 2012, Matthias Klose wrote:
> >>> 
>  Please find attached the patch updated for trunk 20120625, x86 only,
>  tested on x86-linux-gnu, KFreeBSD and the Hurd.
> > 
> >> 2012-06-25  Matthias Klose  
> >> 
> >> * doc/invoke.texi: Document -print-multiarch. * doc/install.texi:
> >> Document --enable-multiarch. * doc/fragments.texi: Document
> >> MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME. * configure.ac: Add
> >> --enable-multiarch option. * configure.in: Regenerate. * Makefile.in
> >> (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib. enable_multiarch,
> >> with_float: New macros. if_multiarch: New macro, define in terms of
> >> enable_multiarch. * genmultilib: Add new argument for the multiarch
> >> name. * gcc.c (multiarch_dir): Define. (for_each_path): Search for
> >> multiarch suffixes. (driver_handle_option): Handle multiarch option. 
> >> (do_spec_1): Pass -imultiarch if defined. (main): Print multiarch. 
> >> (set_multilib_dir): Separate multilib and multiarch names from
> >> multilib_select. (print_multilib_info): Ignore multiarch names in
> >> multilib_select. * incpath.c (add_standard_paths): Search the multiarch
> >> include dirs. * cppdeault.h (default_include): Document multiarch in
> >> multilib member. * cppdefault.c: [LOCAL_INCLUDE_DIR,
> >> STANDARD_INCLUDE_DIR] Add an include directory for multiarch
> >> directories. * common.opt: New options --print-multiarch and -imultilib. 
> >> * config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd for
> >> i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu for
> >> i[34567]86-*-gnu*). * config/i386/t-kfreebsd: Add multiarch names in 
> >> MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME. * config/i386/t-linux64:
> >> Likewise. * config/i386/t-linux: Define MULTIARCH_DIRNAME. *
> >> config/i386/t-gnu: Likewise.
> > 
> > As I said before, »config/i386/t-{gnu,kfreebsd,linux}« are new files. 
> > Instead of repeating: my comments from 
> > 
> >
> > 
> as well as the follow-up still hold.
> 
> Like
> 
>   * config/i386/t-gnu: New, define MULTIARCH_DIRNAME.
> 
> ?

I'd use:

* config/i386/t-gnu: New file.
* config/i386/t-kfreebsd: Likewise.
* config/i386/t-linux: Likewise.

Plus the following instead of your changes:

gcc/
* config.gcc  (tmake_file):
Include i386/t-linux.
 (tmake_file):
Include i386/t-kfreebsd.
 (tmake_file): Include i386/t-gnu.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7ec184c..39c70f2 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3481,9 +3481,14 @@ case ${target} in
 
i[34567]86-*-darwin* | x86_64-*-darwin*)
;;
-   i[34567]86-*-linux* | x86_64-*-linux* | \
- i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
- i[34567]86-*-gnu*)
+   i[34567]86-*-linux* | x86_64-*-linux*)
+   tmake_file="$tmake_file i386/t-linux"
+   ;;
+   i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu)
+   tmake_file="$tmake_file i386/t-kfreebsd"
+   ;;
+   i[34567]86-*-gnu*)
+   tmake_file="$tmake_file i386/t-gnu"
;;
i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
;;

Otherwise, I can't imagine how that would work.


Grüße,
 Thomas


pgpJmqjTH8LJD.pgp
Description: PGP signature

Re: [patch] support for multiarch systems

[Matthias Klose]

On 28.06.2012 12:01, Thomas Schwinge wrote:
> Hi!
> 
> On Mon, 25 Jun 2012 18:19:26 +0200, Matthias Klose 
> wrote:
>> On 25.06.2012 15:56, Joseph S. Myers wrote:
>>> On Mon, 25 Jun 2012, Matthias Klose wrote:
>>> 
 Please find attached the patch updated for trunk 20120625, x86 only,
 tested on x86-linux-gnu, KFreeBSD and the Hurd.
> 
>> 2012-06-25  Matthias Klose  
>> 
>> * doc/invoke.texi: Document -print-multiarch. * doc/install.texi:
>> Document --enable-multiarch. * doc/fragments.texi: Document
>> MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME. * configure.ac: Add
>> --enable-multiarch option. * configure.in: Regenerate. * Makefile.in
>> (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib. enable_multiarch,
>> with_float: New macros. if_multiarch: New macro, define in terms of
>> enable_multiarch. * genmultilib: Add new argument for the multiarch
>> name. * gcc.c (multiarch_dir): Define. (for_each_path): Search for
>> multiarch suffixes. (driver_handle_option): Handle multiarch option. 
>> (do_spec_1): Pass -imultiarch if defined. (main): Print multiarch. 
>> (set_multilib_dir): Separate multilib and multiarch names from
>> multilib_select. (print_multilib_info): Ignore multiarch names in
>> multilib_select. * incpath.c (add_standard_paths): Search the multiarch
>> include dirs. * cppdeault.h (default_include): Document multiarch in
>> multilib member. * cppdefault.c: [LOCAL_INCLUDE_DIR,
>> STANDARD_INCLUDE_DIR] Add an include directory for multiarch
>> directories. * common.opt: New options --print-multiarch and -imultilib. 
>> * config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd for
>> i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu for
>> i[34567]86-*-gnu*). * config/i386/t-kfreebsd: Add multiarch names in 
>> MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME. * config/i386/t-linux64:
>> Likewise. * config/i386/t-linux: Define MULTIARCH_DIRNAME. *
>> config/i386/t-gnu: Likewise.
> 
> As I said before, »config/i386/t-{gnu,kfreebsd,linux}« are new files. 
> Instead of repeating: my comments from 
> 
>
> 
as well as the follow-up still hold.

Like

* config/i386/t-gnu: New, define MULTIARCH_DIRNAME.

?

>> Index: genmultilib 
>> === ---
>> genmultilib  (revision 188931) +++ genmultilib   (working copy) @@ -84,6
>> +84,8 @@ # This argument can be used together with MULTILIB_EXCEPTIONS
>> and will take # effect after the MULTILIB_EXCEPTIONS.
>> 
>> +# The optional eight argument is the multiarch name.
> 
> »ninth argument«.

fixed.

Re: [patch] support for multiarch systems

[Thomas Schwinge]

Hi!

On Mon, 25 Jun 2012 18:19:26 +0200, Matthias Klose  wrote:
> On 25.06.2012 15:56, Joseph S. Myers wrote:
> > On Mon, 25 Jun 2012, Matthias Klose wrote:
> > 
> >> Please find attached the patch updated for trunk 20120625, x86 only, 
> >> tested on
> >> x86-linux-gnu, KFreeBSD and the Hurd.

> 2012-06-25  Matthias Klose  
> 
>   * doc/invoke.texi: Document -print-multiarch.
>   * doc/install.texi: Document --enable-multiarch.
>   * doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
>   * configure.ac: Add --enable-multiarch option.
>   * configure.in: Regenerate.
>   * Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
>   enable_multiarch, with_float: New macros.
>   if_multiarch: New macro, define in terms of enable_multiarch.
>   * genmultilib: Add new argument for the multiarch name.
>   * gcc.c (multiarch_dir): Define.
>   (for_each_path): Search for multiarch suffixes.
>   (driver_handle_option): Handle multiarch option.
>   (do_spec_1): Pass -imultiarch if defined.
>   (main): Print multiarch.
>   (set_multilib_dir): Separate multilib and multiarch names
>   from multilib_select.
>   (print_multilib_info): Ignore multiarch names in multilib_select.
>   * incpath.c (add_standard_paths): Search the multiarch include dirs.
>   * cppdeault.h (default_include): Document multiarch in multilib
>   member.
>   * cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
> include directory for multiarch directories.
>   * common.opt: New options --print-multiarch and -imultilib.
>   * config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd
>   for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
>   for i[34567]86-*-gnu*).
>   * config/i386/t-kfreebsd: Add multiarch names in
>   MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
>   * config/i386/t-linux64: Likewise.
>   * config/i386/t-linux: Define MULTIARCH_DIRNAME.
>   * config/i386/t-gnu: Likewise.

As I said before, »config/i386/t-{gnu,kfreebsd,linux}« are new files.
Instead of repeating: my comments from

as well as the follow-up still hold.

> Index: genmultilib
> ===
> --- genmultilib   (revision 188931)
> +++ genmultilib   (working copy)
> @@ -84,6 +84,8 @@
>  # This argument can be used together with MULTILIB_EXCEPTIONS and will take
>  # effect after the MULTILIB_EXCEPTIONS.
>  
> +# The optional eight argument is the multiarch name.

»ninth argument«.


Grüße,
 Thomas


pgpZRoJXMiArK.pgp
Description: PGP signature

Re: [patch] support for multiarch systems

[Matthias Klose]

On 25.06.2012 15:56, Joseph S. Myers wrote:
> On Mon, 25 Jun 2012, Matthias Klose wrote:
> 
>> Please find attached the patch updated for trunk 20120625, x86 only, tested 
>> on
>> x86-linux-gnu, KFreeBSD and the Hurd.
> 
> This patch appears to include changes to config.gcc for other targets, not 
> mentioned in your ChangeLog entries.  Please resubmit without those 
> changes, and submit them separately with their own rationale if needed.

my mistake, removed these bits now again.

2012-06-25  Matthias Klose  

* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
* config/i386/t-linux64: Likewise.
* config/i386/t-linux: Define MULTIARCH_DIRNAME.
* config/i386/t-gnu: Likewise.

Index: configure.ac
===
--- configure.ac(revision 188931)
+++ configure.ac(working copy)
@@ -623,6 +623,21 @@
 [], [enable_multilib=yes])
 AC_SUBST(enable_multilib)
 
+# Determine whether or not multiarch is enabled.
+AC_ARG_ENABLE(multiarch,
+[AS_HELP_STRING([--enable-multiarch],
+   [enable support for multiarch paths])],
+[case "${withval}" in
+yes|no|auto-detect) enable_multiarch=$withval;;
+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
+esac], [enable_multiarch=auto-detect])
+AC_MSG_CHECKING(for multiarch configuration)
+AC_SUBST(enable_multiarch)
+AC_MSG_RESULT($enable_multiarch)
+
+# needed for setting the multiarch name on ARM
+AC_SUBST(with_float)
+
 # Enable __cxa_atexit for C++.
 AC_ARG_ENABLE(__cxa_atexit,
 [AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
Index: cppdefault.c
===
--- cppdefault.c(revision 188931)
+++ cppdefault.c(working copy)
@@ -63,6 +63,7 @@
 #endif
 #ifdef LOCAL_INCLUDE_DIR
 /* /usr/local/include comes before the fixincluded header files.  */
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
 { LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
 #endif
 #ifdef PREFIX_INCLUDE_DIR
@@ -90,6 +91,7 @@
 #endif
 #ifdef NATIVE_SYSTEM_HEADER_DIR
 /* /usr/include comes dead last.  */
+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
 { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
 #endif
 { 0, 0, 0, 0, 0, 0 }
Index: cppdefault.h
===
--- cppdefault.h(revision 188931)
+++ cppdefault.h(working copy)
@@ -43,9 +43,11 @@
   C++.  */
   const char add_sysroot;  /* FNAME should be prefixed by
   cpp_SYSROOT.  */
-  const char multilib; /* FNAME should have the multilib path
-  specified with -imultilib
-  appended.  */
+  const char multilib; /* FNAME should have appended
+  - the multilib path specified with -imultilib
+when 1 is passed,
+  - the multiarch path specified with
+-imultiarch, when 2 is passed.  */
 };
 
 extern const struct default_include cpp_include_defaults[];
Index: Makefile.in
===
--- Makefile.in (revision 188931)
+++ Makefile.in (working copy)
@@ -350,6 +350,17 @

Re: [patch] support for multiarch systems

[Joseph S. Myers]

On Mon, 25 Jun 2012, Matthias Klose wrote:

> Please find attached the patch updated for trunk 20120625, x86 only, tested on
> x86-linux-gnu, KFreeBSD and the Hurd.

This patch appears to include changes to config.gcc for other targets, not 
mentioned in your ChangeLog entries.  Please resubmit without those 
changes, and submit them separately with their own rationale if needed.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [patch] support for multiarch systems

[Matthias Klose]

Please find attached the patch updated for trunk 20120625, x86 only, tested on
x86-linux-gnu, KFreeBSD and the Hurd.

I left in the comment about the multiarch names, but I'm fine to change/discard
it. It was first required by Joseph Myers, then not found necessary by Paolo
Bonzini.

Ok for the trunk?

  Matthias
2012-06-25  Matthias Klose  

* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
* config/i386/t-linux64: Likewise.
* config/i386/t-linux: Define MULTIARCH_DIRNAME.
* config/i386/t-gnu: Likewise.

Index: configure.ac
===
--- configure.ac(revision 188931)
+++ configure.ac(working copy)
@@ -623,6 +623,21 @@
 [], [enable_multilib=yes])
 AC_SUBST(enable_multilib)
 
+# Determine whether or not multiarch is enabled.
+AC_ARG_ENABLE(multiarch,
+[AS_HELP_STRING([--enable-multiarch],
+   [enable support for multiarch paths])],
+[case "${withval}" in
+yes|no|auto-detect) enable_multiarch=$withval;;
+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
+esac], [enable_multiarch=auto-detect])
+AC_MSG_CHECKING(for multiarch configuration)
+AC_SUBST(enable_multiarch)
+AC_MSG_RESULT($enable_multiarch)
+
+# needed for setting the multiarch name on ARM
+AC_SUBST(with_float)
+
 # Enable __cxa_atexit for C++.
 AC_ARG_ENABLE(__cxa_atexit,
 [AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
Index: cppdefault.c
===
--- cppdefault.c(revision 188931)
+++ cppdefault.c(working copy)
@@ -63,6 +63,7 @@
 #endif
 #ifdef LOCAL_INCLUDE_DIR
 /* /usr/local/include comes before the fixincluded header files.  */
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
 { LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
 #endif
 #ifdef PREFIX_INCLUDE_DIR
@@ -90,6 +91,7 @@
 #endif
 #ifdef NATIVE_SYSTEM_HEADER_DIR
 /* /usr/include comes dead last.  */
+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
 { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
 #endif
 { 0, 0, 0, 0, 0, 0 }
Index: cppdefault.h
===
--- cppdefault.h(revision 188931)
+++ cppdefault.h(working copy)
@@ -43,9 +43,11 @@
   C++.  */
   const char add_sysroot;  /* FNAME should be prefixed by
   cpp_SYSROOT.  */
-  const char multilib; /* FNAME should have the multilib path
-  specified with -imultilib
-  appended.  */
+  const char multilib; /* FNAME should have appended
+  - the multilib path specified with -imultilib
+when 1 is passed,
+  - the multiarch path specified with
+-imultiarch, when 2 is passed.  */
 };
 
 extern const struct default_include cpp_include_defaults[];
Index: Makefile.in
===
--- Makefile.in (revision 188931)
+++ Makefile.in (working copy)
@@ -350,6 +350,17 @@
 
 enable_plugin = @enable_plugin@
 
+# Multiarch support
+enable_multiarch = @enable_multiarch@
+with_float = @with_float@
+ifeq ($(enable_multiarch),yes)
+  if_multiarch 

Re: [patch] support for multiarch systems

[Thomas Schwinge]

Hi!

On Sat, 19 May 2012 18:05:30 +0200, I wrote:
> On Wed, 09 May 2012 02:38:11 +0200, Matthias Klose  wrote:
> > ok, the attached patch includes just the support for the x86 targets, 
> > including
> > the kfreebsd and the hurd systems. The x32 multiarch tuple isn't yet 
> > defined, so
> > I'd like to keep it out of the first version.
> 
> I will test this on/for GNU/Hurd next week (hopefully)

I have now completed this testing: the patch does work correctly when
natively building i686-linux-gnu on Debian GNU/Linux as well as i686-gnu
on Debian GNU/Hurd, and also when building a i686-linux-gnu to i686-gnu
cross-compiler which is not using the Debian multiarch arrangement.

> but here are
> already two comments.
> 
> > Index: gcc/Makefile.in
> > ===
> > --- gcc/Makefile.in (revision 187271)
> > +++ gcc/Makefile.in (working copy)
> > @@ -350,6 +350,17 @@
> >  
> >  enable_plugin = @enable_plugin@
> >  
> > +# Multiarch support
> > +enable_multiarch = @enable_multiarch@
> > +with_float = @with_float@
> > +ifeq ($(enable_multiarch),yes)
> > +  if_multiarch = $(1)
> > +else ifeq ($(enable_multiarch),auto-detect)
> > +  if_multiarch = $(if $(wildcard $(shell echo 
> > $(SYSTEM_HEADER_DIR))/../../usr/lib/*/crti.o),$(1))
> > +else
> > +  if_multiarch =
> > +endif
> 
> The auto-detection won't work for cases where native_system_header_dir
> (as per config.gcc; or command-line argument) is not /usr/include.

This does not really bother me, as my GNU/Hurd configurations also use
/usr/include as opposed to /include, and the auto-detection will work for
that case.

> > Index: gcc/config.gcc
> > ===
> > --- gcc/config.gcc  (revision 187271)
> > +++ gcc/config.gcc  (working copy)
> > @@ -3472,10 +3476,14 @@
> >  
> > i[34567]86-*-darwin* | x86_64-*-darwin*)
> > ;;
> > -   i[34567]86-*-linux* | x86_64-*-linux* | \
> > - i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
> > - i[34567]86-*-gnu*)
> > +   i[34567]86-*-linux* | x86_64-*-linux*)
> > ;;
> > +   i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu)
> > +   tmake_file="${tmake_file} i386/t-linux i386/t-kfreebsd"
> > +   ;;
> > +   i[34567]86-*-gnu*)
> > +   tmake_file="${tmake_file} i386/t-linux i386/t-gnu"
> > +   ;;
> 
> > Index: gcc/config/i386/t-linux
> > ===
> > --- gcc/config/i386/t-linux (revision 0)
> > +++ gcc/config/i386/t-linux (revision 0)
> > @@ -0,0 +1 @@
> > +MULTIARCH_DIRNAME = $(call if_multiarch,i386-linux-gnu)
> > Index: gcc/config/i386/t-gnu
> > ===
> > --- gcc/config/i386/t-gnu   (revision 0)
> > +++ gcc/config/i386/t-gnu   (revision 0)
> > @@ -0,0 +1 @@
> > +MULTIARCH_DIRNAME = $(call if_multiarch,i386-gnu)
> 
> > Index: gcc/config/i386/t-kfreebsd
> > ===
> > --- gcc/config/i386/t-kfreebsd  (revision 0)
> > +++ gcc/config/i386/t-kfreebsd  (revision 0)
> > @@ -0,0 +1,5 @@
> > +MULTIARCH_DIRNAME = $(call if_multiarch,i386-kfreebsd-gnu)
> > +
> > +# MULTILIB_OSDIRNAMES are set in t-linux64.
> > +KFREEBSD_OS = $(filter kfreebsd%, $(word 3, $(subst -, ,$(target
> > +MULTILIB_OSDIRNAMES := $(subst linux,$(KFREEBSD_OS),$(MULTILIB_OSDIRNAMES))
> 
> As of 2011-11-02 (a997b0d8a7b720578f40c0f9f7767bac02022e0b, r180767)
> there was no i386/t-linux anymore, and you're now re-introducing it, so
> you'll need to re-add it for the *-linux* cases cited above, but also
> remove it from the other *-gnu* cases.

gcc/
* config.gcc  (tmake_file):
Include i386/t-linux.
 (tmake_file):
Include i386/t-kfreebsd.
 (tmake_file): Include i386/t-gnu.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7ec184c..39c70f2 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3481,9 +3481,14 @@ case ${target} in
 
i[34567]86-*-darwin* | x86_64-*-darwin*)
;;
-   i[34567]86-*-linux* | x86_64-*-linux* | \
- i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
- i[34567]86-*-gnu*)
+   i[34567]86-*-linux* | x86_64-*-linux*)
+   tmake_file="$tmake_file i386/t-linux"
+   ;;
+   i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu)
+   tmake_file="$tmake_file i386/t-kfreebsd"
+   ;;
+   i[34567]86-*-gnu*)
+   tmake_file="$tmake_file i386/t-gnu"
;;
i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
;;


Grüße,
 Thomas


pgp8TtovDlv4g.pgp
Description: PGP signature

Re: [patch] support for multiarch systems

[Thomas Schwinge]

Hi!

On Wed, 09 May 2012 02:38:11 +0200, Matthias Klose  wrote:
> ok, the attached patch includes just the support for the x86 targets, 
> including
> the kfreebsd and the hurd systems. The x32 multiarch tuple isn't yet defined, 
> so
> I'd like to keep it out of the first version.

I will test this on/for GNU/Hurd next week (hopefully), but here are
already two comments.

> Index: gcc/Makefile.in
> ===
> --- gcc/Makefile.in   (revision 187271)
> +++ gcc/Makefile.in   (working copy)
> @@ -350,6 +350,17 @@
>  
>  enable_plugin = @enable_plugin@
>  
> +# Multiarch support
> +enable_multiarch = @enable_multiarch@
> +with_float = @with_float@
> +ifeq ($(enable_multiarch),yes)
> +  if_multiarch = $(1)
> +else ifeq ($(enable_multiarch),auto-detect)
> +  if_multiarch = $(if $(wildcard $(shell echo 
> $(SYSTEM_HEADER_DIR))/../../usr/lib/*/crti.o),$(1))
> +else
> +  if_multiarch =
> +endif

The auto-detection won't work for cases where native_system_header_dir
(as per config.gcc; or command-line argument) is not /usr/include.

> Index: gcc/config.gcc
> ===
> --- gcc/config.gcc(revision 187271)
> +++ gcc/config.gcc(working copy)
> @@ -3472,10 +3476,14 @@
>  
>   i[34567]86-*-darwin* | x86_64-*-darwin*)
>   ;;
> - i[34567]86-*-linux* | x86_64-*-linux* | \
> -   i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
> -   i[34567]86-*-gnu*)
> + i[34567]86-*-linux* | x86_64-*-linux*)
>   ;;
> + i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu)
> + tmake_file="${tmake_file} i386/t-linux i386/t-kfreebsd"
> + ;;
> + i[34567]86-*-gnu*)
> + tmake_file="${tmake_file} i386/t-linux i386/t-gnu"
> + ;;

> Index: gcc/config/i386/t-linux
> ===
> --- gcc/config/i386/t-linux   (revision 0)
> +++ gcc/config/i386/t-linux   (revision 0)
> @@ -0,0 +1 @@
> +MULTIARCH_DIRNAME = $(call if_multiarch,i386-linux-gnu)
> Index: gcc/config/i386/t-gnu
> ===
> --- gcc/config/i386/t-gnu (revision 0)
> +++ gcc/config/i386/t-gnu (revision 0)
> @@ -0,0 +1 @@
> +MULTIARCH_DIRNAME = $(call if_multiarch,i386-gnu)

> Index: gcc/config/i386/t-kfreebsd
> ===
> --- gcc/config/i386/t-kfreebsd(revision 0)
> +++ gcc/config/i386/t-kfreebsd(revision 0)
> @@ -0,0 +1,5 @@
> +MULTIARCH_DIRNAME = $(call if_multiarch,i386-kfreebsd-gnu)
> +
> +# MULTILIB_OSDIRNAMES are set in t-linux64.
> +KFREEBSD_OS = $(filter kfreebsd%, $(word 3, $(subst -, ,$(target
> +MULTILIB_OSDIRNAMES := $(subst linux,$(KFREEBSD_OS),$(MULTILIB_OSDIRNAMES))

As of 2011-11-02 (a997b0d8a7b720578f40c0f9f7767bac02022e0b, r180767)
there was no i386/t-linux anymore, and you're now re-introducing it, so
you'll need to re-add it for the *-linux* cases cited above, but also
remove it from the other *-gnu* cases.


Grüße,
 Thomas


pgpvaJUXakrU4.pgp
Description: PGP signature

Re: [patch] support for multiarch systems

[Jonathan Nieder]

Paolo Bonzini wrote:
> Il 11/05/2012 07:13, Matthias Klose ha scritto:

>> +The multiarch tuples are defined
>> +in @uref{http://wiki.debian.org/Multiarch/Tuples}.
>
> Is this needed?  Aren't they defined simply by the GCC source code?
> Surely if some other OS implements multiarch with different tuples (no
> matter how undesirable that would be) Debian would not be an
> authoritative source.

Is there some vendor-neutral wiki or other place that would be easy
to update that could be used to define tuples?  I think the table is
currently in that wiki page since that was just the easiest place to
put it.  As soon as there is some place more authoritative the table
could be replaced with a link.

If some other OS implements multiarch with different tuples, that's
no big deal.  An OS implementing multiarch using the same tuples with
incompatible meaning would be more unpleasant.

Jonathan

Re: [patch] support for multiarch systems

[Matthias Klose]

On 11.05.2012 12:51, Paolo Bonzini wrote:
> Il 11/05/2012 07:13, Matthias Klose ha scritto:
>> ok, I did clarify it in the existing documentation of MULTIARCH_DIRNAME in
>> fragments.texi, detailing the search order for the files. Should the search
>> order be mentioned in some user documentation as well? if yes, where?
> 
> Thanks!  I don't think the search order should be mentioned specially,
> since anyway *_INCLUDE_PATH and LIBRARY_PATH are mentioned.  However
> under MULTILIB_DIRNAMES I would add something like this:
> 
> @code{MULTILIB_DIRNAMES} describes the multilib directories using GCC
> conventions and is applied to directories that are part of the GCC
> installation.  When multilib-enabled, the compiler will add a
> subdirectory of the form @var{prefix}/@var{multilib} before each
> directory in the search path for libraries and crt files.

done.

>> +@findex MULTILIB_OSDIRNAMES
>> +@item MULTILIB_OSDIRNAMES
>> +If @code{MULTILIB_OPTIONS} is used, this variable specifies
> 
> ... a list of subdirectory names, that are used to modify the search
> path depending on the chosen multilib.  Unlike @code{MULTILIB_DIRNAMES},
> @code{MULTILIB_OSDIRNAMES} describes the multilib directories using
> operating systems conventions, and is applied to the directories such as
> @code{lib} or those in the @env{LIBRARY_PATH} environment variable.
> 
>>  The format is either the same as of
>> +@code{MULTILIB_DIRNAMES}, or a set of mappings.  When it is the same
>> +as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
>> +using OS conventions, rather than GCC conventions.
> 
> s/OS/operating system/

done.

>> When it is a set
>> +of mappings of the form @var{gccdir}=@var{osdir}, the left side gives
>> +the GCC convention and the right gives the equivalent OS defined
>> +location.  If the @var{osdir} part begins with a @samp{!},
> 
> ... GCC will not search in the non-multilib directory and use
> exclusively the multilib directory.  Otherwise, the compiler will
> examine the search path for libraries and crt files twice; the first
> time it will add @var{multilib} to each directory in the search path,
> the second it will not.
> 
>> Use the mapping when there is
>> +no one-to-one equivalence between GCC levels and the OS.
> 
> I'm not sure what you mean here?

The whole paragraph was taken from the genmultilib script. I left it out for
this version. I think I'll update the genmultilib script when these docs are
settled.

>> +For multilib enabled configurations (see @code{MULTIARCH_DIRNAME})
>> +below), the multilib name is appended to each directory name, separated
>> +by a colon (e.g. @samp{../lib:x86_64-linux-gnu}).
> 
> For configurations that support both multilib and multiarch,
> @code{MULTILIB_OSDIRNAMES} also encodes the multiarch name, thus
> subsuming @code{MULTIARCH_DIRNAME}.  The multiarch name is appended to
> each directory name, separated by a colon (e.g.
> @samp{../lib32:i386-linux-gnu}).
> 
> Each multiarch subdirectory will be searched before the corresponding OS
> multilib directory, for example @samp{/lib/i386-linux-gnu} before
> @samp{/lib/..lib32}.  The multiarch name will also be used to modify the
> system header search path, as explained for @code{MULTIARCH_DIRNAME}.

done.

>> +@findex MULTIARCH_DIRNAME
>> +@item MULTIARCH_DIRNAME
>> +If @code{MULTIARCH_DIRNAME} is used, this variable specifies the
>> +multiarch name for this configuration.
>>
>> +Libraries and crt files are searched first in
>> +@var{prefix}/@var{multiarch} before @var{prefix} for each @var{prefix}
>> +added by @code{add_prefix} or @code{add_sysrooted_prefix}.
>> +System header files are searched first in
>> +@code{LOCAL_INCLUDE_DIR}/@var{multiarch} before
>> +@code{LOCAL_INCLUDE_DIR}, and in
>> +@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch} before
>> +@code{NATIVE_SYSTEM_HEADER_DIR}.
>>
>> +@code{MULTIARCH_DIRNAME} is not used for multilib enabled
>> +configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead.
> 
> This sounds simpler, and doesn't refer to GCC implementation details
> such add_prefix/add_sysrooted_prefix:
> 
> This variable specifies the multiarch name for configurations that are
> multiarch-enabled but not multilibbed configurations.
> 
> The multiarch name is used to augment the search path for libraries, crt
> files and system header files with additional locations.  The compiler
> will add a multiarch subdirectory of the form
> @var{prefix}/@var{multiarch} before each directory in the library and
> crt search path.  It will also add two directories
> @code{LOCAL_INCLUDE_DIR}/@var{multiarch} and
> @code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch}) to the system header
> search path, respectively before @code{LOCAL_INCLUDE_DIR} and
> @code{NATIVE_SYSTEM_HEADER_DIR}.
> 
> @code{MULTIARCH_DIRNAME} is not used for configurations that support
> both multilib and multiarch.  In that case, multiarch names are encoded
> in @code{MULTILIB_OSDIRNAMES} instead.

done. thanks for the wording.

Re: [patch] support for multiarch systems

[Paolo Bonzini]

Il 11/05/2012 07:13, Matthias Klose ha scritto:
> ok, I did clarify it in the existing documentation of MULTIARCH_DIRNAME in
> fragments.texi, detailing the search order for the files. Should the search
> order be mentioned in some user documentation as well? if yes, where?

Thanks!  I don't think the search order should be mentioned specially,
since anyway *_INCLUDE_PATH and LIBRARY_PATH are mentioned.  However
under MULTILIB_DIRNAMES I would add something like this:

@code{MULTILIB_DIRNAMES} describes the multilib directories using GCC
conventions and is applied to directories that are part of the GCC
installation.  When multilib-enabled, the compiler will add a
subdirectory of the form @var{prefix}/@var{multilib} before each
directory in the search path for libraries and crt files.

> +@findex MULTILIB_OSDIRNAMES
> +@item MULTILIB_OSDIRNAMES
> +If @code{MULTILIB_OPTIONS} is used, this variable specifies

... a list of subdirectory names, that are used to modify the search
path depending on the chosen multilib.  Unlike @code{MULTILIB_DIRNAMES},
@code{MULTILIB_OSDIRNAMES} describes the multilib directories using
operating systems conventions, and is applied to the directories such as
@code{lib} or those in the @env{LIBRARY_PATH} environment variable.

>  The format is either the same as of
> +@code{MULTILIB_DIRNAMES}, or a set of mappings.  When it is the same
> +as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
> +using OS conventions, rather than GCC conventions.

s/OS/operating system/

> When it is a set
> +of mappings of the form @var{gccdir}=@var{osdir}, the left side gives
> +the GCC convention and the right gives the equivalent OS defined
> +location.  If the @var{osdir} part begins with a @samp{!},

... GCC will not search in the non-multilib directory and use
exclusively the multilib directory.  Otherwise, the compiler will
examine the search path for libraries and crt files twice; the first
time it will add @var{multilib} to each directory in the search path,
the second it will not.

> Use the mapping when there is
> +no one-to-one equivalence between GCC levels and the OS.

I'm not sure what you mean here?


> +For multilib enabled configurations (see @code{MULTIARCH_DIRNAME})
> +below), the multilib name is appended to each directory name, separated
> +by a colon (e.g. @samp{../lib:x86_64-linux-gnu}).

For configurations that support both multilib and multiarch,
@code{MULTILIB_OSDIRNAMES} also encodes the multiarch name, thus
subsuming @code{MULTIARCH_DIRNAME}.  The multiarch name is appended to
each directory name, separated by a colon (e.g.
@samp{../lib32:i386-linux-gnu}).

Each multiarch subdirectory will be searched before the corresponding OS
multilib directory, for example @samp{/lib/i386-linux-gnu} before
@samp{/lib/..lib32}.  The multiarch name will also be used to modify the
system header search path, as explained for @code{MULTIARCH_DIRNAME}.


> +@findex MULTIARCH_DIRNAME
> +@item MULTIARCH_DIRNAME
> +If @code{MULTIARCH_DIRNAME} is used, this variable specifies the
> +multiarch name for this configuration.
>
> +Libraries and crt files are searched first in
> +@var{prefix}/@var{multiarch} before @var{prefix} for each @var{prefix}
> +added by @code{add_prefix} or @code{add_sysrooted_prefix}.
> +System header files are searched first in
> +@code{LOCAL_INCLUDE_DIR}/@var{multiarch} before
> +@code{LOCAL_INCLUDE_DIR}, and in
> +@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch} before
> +@code{NATIVE_SYSTEM_HEADER_DIR}.
>
> +@code{MULTIARCH_DIRNAME} is not used for multilib enabled
> +configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead.

This sounds simpler, and doesn't refer to GCC implementation details
such add_prefix/add_sysrooted_prefix:

This variable specifies the multiarch name for configurations that are
multiarch-enabled but not multilibbed configurations.

The multiarch name is used to augment the search path for libraries, crt
files and system header files with additional locations.  The compiler
will add a multiarch subdirectory of the form
@var{prefix}/@var{multiarch} before each directory in the library and
crt search path.  It will also add two directories
@code{LOCAL_INCLUDE_DIR}/@var{multiarch} and
@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch}) to the system header
search path, respectively before @code{LOCAL_INCLUDE_DIR} and
@code{NATIVE_SYSTEM_HEADER_DIR}.

@code{MULTIARCH_DIRNAME} is not used for configurations that support
both multilib and multiarch.  In that case, multiarch names are encoded
in @code{MULTILIB_OSDIRNAMES} instead.

> +The multiarch tuples are defined
> +in @uref{http://wiki.debian.org/Multiarch/Tuples}.

Is this needed?  Aren't they defined simply by the GCC source code?
Surely if some other OS implements multiarch with different tuples (no
matter how undesirable that would be) Debian would not be an
authoritative source.

Paolo

Re: [patch] support for multiarch systems

[Matthias Klose]

On 10.05.2012 08:42, Paolo Bonzini wrote:
> Il 09/05/2012 19:19, Matthias Klose ha scritto:
>> these are referenced from the http://wiki.debian.org/Multiarch/Tuples
>> https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout
>> http://err.no/debian/amd64-multiarch-3
>>
>> http://wiki.debian.org/Multiarch/TheCaseForMultiarch describes use cases for
>> multiarch, and why Debian thinks that the existing approaches are not 
>> sufficient
>> (having name collisions for different architectures or ad hoc names for new
>> architectures like libx32).  That may be contentious within the Linux 
>> community,
>> but I would like to avoid this kind of discussion here.
> 
> I don't care about contentiousness, I just would like this to be
> documented somewhere (for example in the internals manual where
> MULTILIB_* is documented too).

ok, I did clarify it in the existing documentation of MULTIARCH_DIRNAME in
fragments.texi, detailing the search order for the files. Should the search
order be mentioned in some user documentation as well? if yes, where?

  Matthias

Index: doc/fragments.texi
===
--- doc/fragments.texi  (revision 187337)
+++ doc/fragments.texi  (working copy)
@@ -152,6 +152,52 @@
 of options to be used for all builds.  If you set this, you should
 probably set @code{CRTSTUFF_T_CFLAGS} to a dash followed by it.
 
+@findex MULTILIB_OSDIRNAMES
+@item MULTILIB_OSDIRNAMES
+If @code{MULTILIB_OPTIONS} is used, this variable specifies the list
+of OS subdirectory names.  The format is either the same as of
+@code{MULTILIB_DIRNAMES}, or a set of mappings.  When it is the same
+as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
+using OS conventions, rather than GCC conventions.  When it is a set
+of mappings of the form @var{gccdir}=@var{osdir}, the left side gives
+the GCC convention and the right gives the equivalent OS defined
+location.  If the @var{osdir} part begins with a @samp{!}, the os
+directory names are used exclusively.  Use the mapping when there is
+no one-to-one equivalence between GCC levels and the OS.
+
+For multilib enabled configurations (see @code{MULTIARCH_DIRNAME})
+below), the multilib name is appended to each directory name, separated
+by a colon (e.g. @samp{../lib:x86_64-linux-gnu}).
+
+@findex MULTIARCH_DIRNAME
+@item MULTIARCH_DIRNAME
+If @code{MULTIARCH_DIRNAME} is used, this variable specifies the
+multiarch name for this configuration.  For multiarch enabled
+configurations it is used to search libraries, crt files and system
+header files in additional locations.
+
+Libraries and crt files are searched first in
+@var{prefix}/@var{multiarch} before @var{prefix} for each @var{prefix}
+added by @code{add_prefix} or @code{add_sysrooted_prefix}.
+System header files are searched first in
+@code{LOCAL_INCLUDE_DIR}/@var{multiarch} before
+@code{LOCAL_INCLUDE_DIR}, and in
+@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch} before
+@code{NATIVE_SYSTEM_HEADER_DIR}.
+
+E.g. for a multiarch enabled system compiler
+@file{/lib/@var{multiarch}} is searched before @file{/lib} and
+@file{/usr/lib/@var{multiarch}} before @file{/usr/lib}, and system
+header files are searched in @file{/usr/local/include/@var{multiarch}}
+before @file{/usr/local/include} and in
+@file{/usr/include/@var{multiarch}} before @file{/usr/include}.
+
+@code{MULTIARCH_DIRNAME} is not used for multilib enabled
+configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead.
+
+The multiarch tuples are defined
+in @uref{http://wiki.debian.org/Multiarch/Tuples}.
+
 @findex SPECS
 @item SPECS
 Unfortunately, setting @code{MULTILIB_EXTRA_OPTS} is not enough, since

Re: [patch] support for multiarch systems

[Paolo Bonzini]

Il 09/05/2012 19:19, Matthias Klose ha scritto:
> these are referenced from the http://wiki.debian.org/Multiarch/Tuples
> https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout
> http://err.no/debian/amd64-multiarch-3
> 
> http://wiki.debian.org/Multiarch/TheCaseForMultiarch describes use cases for
> multiarch, and why Debian thinks that the existing approaches are not 
> sufficient
> (having name collisions for different architectures or ad hoc names for new
> architectures like libx32).  That may be contentious within the Linux 
> community,
> but I would like to avoid this kind of discussion here.

I don't care about contentiousness, I just would like this to be
documented somewhere (for example in the internals manual where
MULTILIB_* is documented too).

Paolo

Re: [patch] support for multiarch systems

[Matthias Klose]

On 09.05.2012 18:29, Paolo Bonzini wrote:
> Il 09/05/2012 17:34, Matthias Klose ha scritto:
 So -print-multiarch is like --print-multi-os-directory?
>> the former prints the part before the `:' in the MULTILIB_OSDIRNAMES, the 
>> latter
>> the part after the `':', e.g. ../lib32 and i386-linux-gnu.
> 
> Yes, of course.
> 
 What is the difference, and where is it documented?
>> Not sure how it should be further documented.
> 
> No idea, it is a new concept and people need to understand how it
> relates to multilibbing for example, what shortcomings are addressed etc.
> 
> I went through the Debian pages (only cursorily, I admit) and I found
> nothing of this.

these are referenced from the http://wiki.debian.org/Multiarch/Tuples
https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout
http://err.no/debian/amd64-multiarch-3

http://wiki.debian.org/Multiarch/TheCaseForMultiarch describes use cases for
multiarch, and why Debian thinks that the existing approaches are not sufficient
(having name collisions for different architectures or ad hoc names for new
architectures like libx32).  That may be contentious within the Linux community,
but I would like to avoid this kind of discussion here.

> Another question I have is related to usage of the option.  Are you
> supposed to look for libraries in the multilib directories too if the
> compiler is multiarch-enabled?

Debian/Ubuntu always use /lib for the default MULTIOSDIR, and this needs to be
looked up in the future too. The use of locations like ../lib32 will be faded
out over time, but I don't see any harm not to have looked up as well.

> Or only in /lib/i386-linux-gnu?  Which
> one takes priority, multiarch or multiosdir?
> 
> From the patch I can guess the intended search path is
> /lib/MULTIARCH:/lib/MULTIOSDIR, but I'm not entirely sure about that and
> it needs documentation.

yes, this is the intended search path. I assume such kind of documentation
shouldn't go into invoke.texi.

 Should it fail if multiarch support is not compiled in?
>> All the -print options always succeed. I would prefer if it just prints the
>> empty string if it is not configured (as it does now).
> 
> Will the empty string be a valid output for a multiarch-enabled
> compiler?  For example "gcc --print-multi-os-directory" and "gcc
> --print-multi-directory" on a bi-arch x86-64 compiler will never print
> the empty string.  Again, I guess the answer is no but I'm not sure.
> 
> If the answer is no, returning the empty string is fine.

The answer is no. If multiarch is enabled, then the string is always non-empty
and should return a multiarch tuple as defined in
http://wiki.debian.org/Multiarch/Tuples. Anything else should be considered an
error.

> If the answer is yes, and assuming the search path is
> /lib/MULTIARCH:/lib/MULTIOSDIR, then programs need to know whether they
> need to omit the /lib/MULTIARCH component of the search path.

Unrelated, but why would programs hard code this path and not use something like
this?

gcc -v -E - &1 | grep ^LIBRARY_PATH

  Matthias

Re: [patch] support for multiarch systems

[Paolo Bonzini]

Il 09/05/2012 17:34, Matthias Klose ha scritto:
>> > So -print-multiarch is like --print-multi-os-directory?
> the former prints the part before the `:' in the MULTILIB_OSDIRNAMES, the 
> latter
> the part after the `':', e.g. ../lib32 and i386-linux-gnu.

Yes, of course.

>> > What is the difference, and where is it documented?
> Not sure how it should be further documented.

No idea, it is a new concept and people need to understand how it
relates to multilibbing for example, what shortcomings are addressed etc.

I went through the Debian pages (only cursorily, I admit) and I found
nothing of this.

Another question I have is related to usage of the option.  Are you
supposed to look for libraries in the multilib directories too if the
compiler is multiarch-enabled?  Or only in /lib/i386-linux-gnu?  Which
one takes priority, multiarch or multiosdir?

>From the patch I can guess the intended search path is
/lib/MULTIARCH:/lib/MULTIOSDIR, but I'm not entirely sure about that and
it needs documentation.

>> > Should it fail if multiarch support is not compiled in?
> All the -print options always succeed. I would prefer if it just prints the
> empty string if it is not configured (as it does now).

Will the empty string be a valid output for a multiarch-enabled
compiler?  For example "gcc --print-multi-os-directory" and "gcc
--print-multi-directory" on a bi-arch x86-64 compiler will never print
the empty string.  Again, I guess the answer is no but I'm not sure.

If the answer is no, returning the empty string is fine.

If the answer is yes, and assuming the search path is
/lib/MULTIARCH:/lib/MULTIOSDIR, then programs need to know whether they
need to omit the /lib/MULTIARCH component of the search path.  A failure
status code is then required.

Paolo

Re: [patch] support for multiarch systems

[Matthias Klose]

On 09.05.2012 15:37, Paolo Bonzini wrote:
> Il 09/05/2012 02:38, Matthias Klose ha scritto:
>> Index: gcc/doc/invoke.texi
>> ===
>> --- gcc/doc/invoke.texi  (revision 187271)
>> +++ gcc/doc/invoke.texi  (working copy)
>> @@ -6110,6 +6110,11 @@
>>  @file{../lib32}, or if OS libraries are present in @file{lib/@var{subdir}}
>>  subdirectories it prints e.g.@: @file{amd64}, @file{sparcv9} or @file{ev6}.
>>  
>> +@item -print-multiarch
>> +@opindex print-multiarch
>> +Print the path to OS libraries for the selected multiarch,
>> +relative to some @file{lib} subdirectory.
>> +
>>  @item -print-prog-name=@var{program}
>>  @opindex print-prog-name
>>  Like @option{-print-file-name}, but searches for a program such as 
>> @samp{cpp}.
> 
> So -print-multiarch is like --print-multi-os-directory?

the former prints the part before the `:' in the MULTILIB_OSDIRNAMES, the latter
the part after the `':', e.g. ../lib32 and i386-linux-gnu.

> What is the difference, and where is it documented?

Not sure how it should be further documented.

> Should it fail if multiarch support is not compiled in?

All the -print options always succeed. I would prefer if it just prints the
empty string if it is not configured (as it does now).

  Matthias

Re: [patch] support for multiarch systems

[Paolo Bonzini]

Il 09/05/2012 02:38, Matthias Klose ha scritto:
> Index: gcc/doc/invoke.texi
> ===
> --- gcc/doc/invoke.texi   (revision 187271)
> +++ gcc/doc/invoke.texi   (working copy)
> @@ -6110,6 +6110,11 @@
>  @file{../lib32}, or if OS libraries are present in @file{lib/@var{subdir}}
>  subdirectories it prints e.g.@: @file{amd64}, @file{sparcv9} or @file{ev6}.
>  
> +@item -print-multiarch
> +@opindex print-multiarch
> +Print the path to OS libraries for the selected multiarch,
> +relative to some @file{lib} subdirectory.
> +
>  @item -print-prog-name=@var{program}
>  @opindex print-prog-name
>  Like @option{-print-file-name}, but searches for a program such as 
> @samp{cpp}.

So -print-multiarch is like --print-multi-os-directory?  What is the
difference, and where is it docuemnted?  Should it fail if multiarch
support is not compiled in?

Paolo

Re: [patch] support for multiarch systems

[Matthias Klose]

On 08.05.2012 15:20, Joseph S. Myers wrote:
> On Tue, 8 May 2012, Matthias Klose wrote:
> 
>> On 20.08.2011 21:51, Matthias Klose wrote:
>>> Multiarch [1] is the term being used to refer to the capability of a system 
>>> to
>>> install and run applications of multiple different binary targets on the 
>>> same
>>> system.
>>
>> please find attached an updated for the trunk (2012-05-08). The multiarch
>> triplets are now defined in the Debian Wiki [1], and progress is made to get 
>> the
>> triplet definitions into Debian Policy [2].
> 
> This still seems to suffer in some cases the problem of previous versions 
> that it does not ensure triplets are never used for non-matching ABIs.  
> For example, a compiler for powerpc-linux-gnu can be configured 
> --with-float=soft but this patch will still use powerpc-linux-gnu as the 
> multiarch triplet.
> 
> For MIPS, I see you allowed for soft-float in setting the triplets - but 
> the specification you point to doesn't mention the soft-float triplets.  
> Likewise you allowed for powerpc-linux-gnuspe being e500v1 or e500v2 but 
> haven't documented the e500v1 triplet.  Likewise for big-endian ARM.
> 
> I again suggest starting with a patch that does just one architecture - 
> but makes sure to cover all the ABIs applicable to that architecture.  
> For example, you could start with a patch for x86 (indeed, just x86 
> GNU/Linux) - and assign a multiarch triplet for x32 even if you're not 
> building an x32 distribution with multiarch.  Then, once the generic 
> support has been reviewed by build system maintainers, and the x86 support 
> by x86 maintainers and people familiar with all the applicable x86 ABIs, 
> send patches for each other architecture (or architecture/OS combination), 
> and the relevant architecture experts can review them to make sure the 
> relevant ABIs are properly distinguished.

ok, the attached patch includes just the support for the x86 targets, including
the kfreebsd and the hurd systems. The x32 multiarch tuple isn't yet defined, so
I'd like to keep it out of the first version.

  Matthias
gcc/

2012-05-08  Matthias Klose  

* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in MULTILIB_OSDIRNAMES,
Define MULTIARCH_DIRNAME.
* config/i386/t-linux64: Likewise.
* config/i386/t-gnu: Likewise:
* config/i386/t-linux: Likewise.

Index: gcc/common.opt
===
--- gcc/common.opt  (revision 187271)
+++ gcc/common.opt  (working copy)
@@ -345,6 +345,9 @@
 -print-multi-os-directory
 Driver Alias(print-multi-os-directory)
 
+-print-multiarch
+Driver Alias(print-multiarch)
+
 -print-prog-name
 Driver Separate Alias(print-prog-name=)
 
@@ -2286,6 +2289,10 @@
 Common Joined Var(plugindir_string) Init(0)
 -iplugindir=  Set  to be the default plugin directory
 
+imultiarch
+Common Joined Separate RejectDriver Var(imultiarch) Init(0)
+-imultiarch   Set  to be the multiarch include subdirectory
+
 l
 Driver Joined Separate
 
@@ -2342,6 +2349,9 @@
 
 print-multi-os-directory
 Driver Var(print_multi_os_directory)
+ 
+print-multiarch
+Driver Var(print_multiarch)
 
 print-prog-name=
 Driver JoinedOrMissing Var(print_prog_name)
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 187271)
+++ gcc/Makefile.in (working copy)
@@ -350,6 +350,17 @@
 
 enable_plugin = @enable_plugin@
 
+# Multiarch support
+enable_multiarch =

Re: [patch] support for multiarch systems

[Joseph S. Myers]

On Tue, 8 May 2012, Matthias Klose wrote:

> On 20.08.2011 21:51, Matthias Klose wrote:
> > Multiarch [1] is the term being used to refer to the capability of a system 
> > to
> > install and run applications of multiple different binary targets on the 
> > same
> > system.
> 
> please find attached an updated for the trunk (2012-05-08). The multiarch
> triplets are now defined in the Debian Wiki [1], and progress is made to get 
> the
> triplet definitions into Debian Policy [2].

This still seems to suffer in some cases the problem of previous versions 
that it does not ensure triplets are never used for non-matching ABIs.  
For example, a compiler for powerpc-linux-gnu can be configured 
--with-float=soft but this patch will still use powerpc-linux-gnu as the 
multiarch triplet.

For MIPS, I see you allowed for soft-float in setting the triplets - but 
the specification you point to doesn't mention the soft-float triplets.  
Likewise you allowed for powerpc-linux-gnuspe being e500v1 or e500v2 but 
haven't documented the e500v1 triplet.  Likewise for big-endian ARM.

I again suggest starting with a patch that does just one architecture - 
but makes sure to cover all the ABIs applicable to that architecture.  
For example, you could start with a patch for x86 (indeed, just x86 
GNU/Linux) - and assign a multiarch triplet for x32 even if you're not 
building an x32 distribution with multiarch.  Then, once the generic 
support has been reviewed by build system maintainers, and the x86 support 
by x86 maintainers and people familiar with all the applicable x86 ABIs, 
send patches for each other architecture (or architecture/OS combination), 
and the relevant architecture experts can review them to make sure the 
relevant ABIs are properly distinguished.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [patch] support for multiarch systems

[Matthias Klose]

On 20.08.2011 21:51, Matthias Klose wrote:
> Multiarch [1] is the term being used to refer to the capability of a system to
> install and run applications of multiple different binary targets on the same
> system.

please find attached an updated for the trunk (2012-05-08). The multiarch
triplets are now defined in the Debian Wiki [1], and progress is made to get the
triplet definitions into Debian Policy [2].

  Matthias

[1] http://wiki.debian.org/Multiarch/Tuples
[2] http://bugs.debian.org/664257

gcc/

2012-05-08  Matthias Klose  

* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file (alpha/t-linux
for alpha*-*-linux*, pa/t-linux for hppa*64*-*-linux*, ia64/t-glibc
for ia64*-*-linux*, rs6000/t-linux for powerpc-*-linux*, i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in MULTILIB_OSDIRNAMES,
Define MULTIARCH_DIRNAME.
* config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux64: Likewise.
* config/rs6000/t-linux64: Likewise.
* config/i386/t-linux64: Likewise.
* config/mips/t-linux64: Likewise.
* config/alpha/t-linux: Define MULTIARCH_DIRNAME.
* config/arm/t-linux-eabi: Likewise.
* config/i386/t-gnu: Likewise:
* config/i386/t-linux: Likewise.
* config/pa/t-linux: Likewise.
* config/rs6000/t-linux: Likewise.
* config/rs6000/t-spe: Likewise.
* config/sparc/t-linux: Likewise.
* config/ia64/t-glibc: Define MULTIARCH_DIRNAME for linux target.

Index: libstdc++-v3/python/hook.in
===
--- libstdc++-v3/python/hook.in (revision 187271)
+++ libstdc++-v3/python/hook.in (working copy)
@@ -47,7 +47,10 @@
 libdir = libdir[len (prefix):]
 
 # Compute the ".."s needed to get from libdir to the prefix.
-dotdots = ('..' + os.sep) * len (libdir.split (os.sep))
+backdirs = len (libdir.split (os.sep))
+if not os.path.basename(os.path.dirname(__file__)).startswith('lib'):
+backdirs += 1 # multiarch subdir
+dotdots = ('..' + os.sep) * backdirs
 
 objfile = gdb.current_objfile ().filename
 dir_ = os.path.join (os.path.dirname (objfile), dotdots, pythondir)
Index: gcc/common.opt
===
--- gcc/common.opt  (revision 187271)
+++ gcc/common.opt  (working copy)
@@ -345,6 +345,9 @@
 -print-multi-os-directory
 Driver Alias(print-multi-os-directory)
 
+-print-multiarch
+Driver Alias(print-multiarch)
+
 -print-prog-name
 Driver Separate Alias(print-prog-name=)
 
@@ -2286,6 +2289,10 @@
 Common Joined Var(plugindir_string) Init(0)
 -iplugindir=  Set  to be the default plugin directory
 
+imultiarch
+Common Joined Separate RejectDriver Var(imultiarch) Init(0)
+-imultiarch   Set  to be the multiarch include subdirectory
+
 l
 Driver Joined Separate
 
@@ -2342,6 +2349,9 @@
 
 print-multi-os-directory
 Driver Var(print_multi_os_directory)
+ 
+print-multiarch
+Driver Var(print_multiarch)
 
 print-prog-name=
 Driver JoinedOrMissing Var(print_prog_name)
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 187271)
+++ gcc/Makefile.in (working copy)
@@ -350,6 +350,17 @@
 
 enable_plugin = @enable_plugin@
 
+# Multiarch support
+enable_multiarch = @enable_multiarch@
+with_float = @with_float@
+ifeq ($(enable_multiarch),yes)
+  if_multiarch = $(1)
+else ifeq ($(enable_multiarch),auto-detect)
+  if_multiarch = $(if $(wildcar

Re: [patch] support for multiarch systems

[Joseph S. Myers]

On Tue, 1 Nov 2011, Marc Glisse wrote:

> On Sun, 21 Aug 2011, Matthias Klose wrote:
> 
> > On 08/20/2011 09:51 PM, Matthias Klose wrote:
> > > Multiarch [1] is the term being used to refer to the capability of a
> > > system to
> > > install and run applications of multiple different binary targets on the
> > > same
> > > system.  The idea and name of multiarch dates back to 2004/2005 [2] (to be
> > > confused with multiarch in glibc).
> > 
> > attached is an updated patch which includes feedback from Jakub and Joseph.
> 
> Hello,
> 
> what is the status of this patch? Is it waiting for a review? Having gcc 4.7
> work out of the box on 2 of the most popular linux distributions seems like an
> important feature...

There were comments of mine that remained unaddressed in the version to 
which you replied and I don't recall a version that addressed them.  So 
there isn't a patch ready for review.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [patch] support for multiarch systems

[Marc Glisse]

On Sun, 21 Aug 2011, Matthias Klose wrote:


On 08/20/2011 09:51 PM, Matthias Klose wrote:

Multiarch [1] is the term being used to refer to the capability of a system to
install and run applications of multiple different binary targets on the same
system.  The idea and name of multiarch dates back to 2004/2005 [2] (to be
confused with multiarch in glibc).


attached is an updated patch which includes feedback from Jakub and Joseph.


Hello,

what is the status of this patch? Is it waiting for a review? Having gcc 
4.7 work out of the box on 2 of the most popular linux distributions seems 
like an important feature...


--
Marc Glisse

Re: [patch] support for multiarch systems

[Thomas Schwinge]

Hi!

On Sun, 21 Aug 2011 02:14:10 +0200, Matthias Klose  wrote:
Non-text part: multipart/mixed
> On 08/20/2011 09:51 PM, Matthias Klose wrote:
> > Multiarch [1] is the term being used to refer to the capability of a system 
> > to
> > install and run applications of multiple different binary targets on the 
> > same
> > system.  The idea and name of multiarch dates back to 2004/2005 [2] (to be
> > confused with multiarch in glibc).
> 
> attached is an updated patch which includes feedback from Jakub and Joseph.

I can confirm that this restores out-of-the box GCC bootstrap on Debian
GNU/Linux testing 386 and Debian GNU/Hurd unstable i386.  Thanks!

A hint for the kids trying this patch at home: don't forget to regenerate
gcc/configure...  (Saves you some hours...)  ;-)


Matthias, please put the following patch on top, though.  (For preserving
the order of using i386/t-linux (which should be renamed i386/t-gnu-user,
but that's for another day) and i386/t-{gnu,kfreebsd}.

* gcc/config.gcc 
: Take care to put their configuration files after
the i386/t-linux one.
 
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 784ddd7..7d0214f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1317,14 +1317,12 @@ i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | 
i[34567]86-*-knetbsd*-gnu | i
;;
i[34567]86-*-kfreebsd*-gnu)
tm_file="${tm_file} i386/gnu-user.h kfreebsd-gnu.h 
i386/kfreebsd-gnu.h"
-   tmake_file="${tmake_file} i386/t-kfreebsd"
;;
i[34567]86-*-kopensolaris*-gnu)
tm_file="${tm_file} i386/gnu-user.h kopensolaris-gnu.h 
i386/kopensolaris-gnu.h"
;;
i[34567]86-*-gnu*)
tm_file="$tm_file i386/gnu-user.h gnu.h i386/gnu.h"
-   tmake_file="${tmake_file} i386/t-gnu"
;;
esac
tmake_file="${tmake_file} i386/t-crtstuff"
@@ -3587,11 +3585,15 @@ case ${target} in
 
i[34567]86-*-darwin* | x86_64-*-darwin*)
;;
-   i[34567]86-*-linux* | x86_64-*-linux* | \
- i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
- i[34567]86-*-gnu*)
+   i[34567]86-*-linux* | x86_64-*-linux*)
tmake_file="${tmake_file} i386/t-linux"
;;
+   i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu)
+   tmake_file="${tmake_file} i386/t-linux i386/t-kfreebsd"
+   ;;
+   i[34567]86-*-gnu*)
+   tmake_file="${tmake_file} i386/t-linux i386/t-gnu"
+   ;;
i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
;;
i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)


Grüße,
 Thomas


pgp84Dl6hIS8C.pgp
Description: PGP signature

Re: [patch] support for multiarch systems

[Toon Moene]

On 08/21/2011 02:14 AM, Matthias Klose wrote:


On 08/20/2011 09:51 PM, Matthias Klose wrote:



Multiarch [1] is the term being used to refer to the capability of a system to
install and run applications of multiple different binary targets on the same
system.  The idea and name of multiarch dates back to 2004/2005 [2] (to be
confused with multiarch in glibc).


attached is an updated patch which includes feedback from Jakub and Joseph.


Perhaps I could "like" this patch ?  It probably solves

http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg02398.html

[ My system is Debian Testing, updated 20110821 at 12:15 UTC ]

(h/t Mark Glisse).

Thanks in advance,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: [patch] support for multiarch systems

[Joseph S. Myers]

On Sun, 21 Aug 2011, Matthias Klose wrote:

> powerpc-linux-gnuspe

As noted, that's ambiguous; --enable-e500-double determines whether it's 
e500v1 or e500v2, and since those have slightly different symbols exported 
from libc I think they should be considered different here.

> > For MIPS, the hard-float and soft-float ABIs are incompatible.  So you 
> > need twelve triplets, not six.
> 
> yes. but I didn't see a soft-float mips port yet.

You can configure MIPS targets (including multilib MIPS64 ones) using 
--with-float=soft, so need to allow for that.

> > For ARM, you have a ChangeLog entry with no corresponding patch.  You need 
> > to distinguish big and little endian; old ABI, EABI soft-float ABI and 
> > EABI hard-float ABI (six triplets).
> 
> ok, added. Debian has little endian ports only. I see that dpkg treats the
> obsolete armeb port as armeb-linux-gnu.

The arm*-*-linux* config.gcc code has

arm*b-*)
tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
;;
esac

so again this should affect whether "eb" goes in the name.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [patch] support for multiarch systems

[Andrew Pinski]

On Sat, Aug 20, 2011 at 5:11 PM, Matthias Klose  wrote:
>> For MIPS, the hard-float and soft-float ABIs are incompatible.  So you
>> need twelve triplets, not six.
>
> yes. but I didn't see a soft-float mips port yet.

We at Cavium has a soft-float mips port and in fact use debian as a
base OS for o32 (but hard float) and have our own n32/n64 libraries
which are soft-float.  mips64octeon-linux-gnu is a soft-float port
which can be used right now; I use that triplet right now to build GCC
on this soft-float based port.

Thanks,
Andrew Pinski

Re: [patch] support for multiarch systems

[Matthias Klose]

On 08/20/2011 09:51 PM, Matthias Klose wrote:
> Multiarch [1] is the term being used to refer to the capability of a system to
> install and run applications of multiple different binary targets on the same
> system.  The idea and name of multiarch dates back to 2004/2005 [2] (to be
> confused with multiarch in glibc).

attached is an updated patch which includes feedback from Jakub and Joseph.

  Matthias

2011-08-21  Matthias Klose  

* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi (MULTILIB_OSDIRNAMES): Document optional
multiarch name. (MULTIARCH_DIRNAME): Document.
* configure.ac: New option --enable-multiarch. Substitute with_float.
* configure: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
(if_multiarch): Helper macro for use in tmake_files.
(with_float): Define.
* genmultilib: Add new option for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux64: Likewise.
* config/powerpc/t-linux64: Likewise.
* config/i386/t-linux64: Likewise.
* config/mips/t-linux64: Likewise.
* config/alpha/t-linux: Define MULTIARCH_DIRNAME.
* config/arm/t-linux: Likewise.
* config/i386/t-linux: Likewise.
* config/pa/t-linux: Likewise.
* config/sparc/t-linux: Likewise.
* config/ia64/t-glibc: Define MULTIARCH_DIRNAME for linux target.
* gcc/config/i386/t-gnu: New, Define MULTIARCH_DIRNAME.
* gcc/config/i386/t-kfreebsd: New, Define MULTIARCH_DIRNAME and
MULTILIB_OSDIRNAMES.



Index: gcc/doc/fragments.texi
===
--- gcc/doc/fragments.texi  (revision 177846)
+++ gcc/doc/fragments.texi  (working copy)
@@ -128,6 +128,33 @@
 of options to be used for all builds.  If you set this, you should
 probably set @code{CRTSTUFF_T_CFLAGS} to a dash followed by it.
 
+@findex MULTILIB_OSDIRNAMES
+@item MULTILIB_OSDIRNAMES
+If @code{MULTILIB_OPTIONS} is used, this variable specifies the list
+of OS subdirectory names.  The format is either the same as of
+@code{MULTILIB_DIRNAMES}, or a set of mappings.  When it is the same
+as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
+using OS conventions, rather than GCC conventions.  When it is a set
+of mappings of the form @var{gccdir}=@var{osdir}, the left side gives
+the GCC convention and the right gives the equivalent OS defined
+location.  If the @var{osdir} part begins with a @samp{!}, the os
+directory names are used exclusively.  Use the mapping when there is
+no one-to-one equivalence between GCC levels and the OS.
+
+For multilib enabled configurations (see @code{MULTIARCH_DIRNAME})
+below), the multilib name is appended to each directory name, separated
+by a colon (e.g. @samp{../lib:x86_64-linux-gnu}).
+
+@findex MULTIARCH_DIRNAME
+@item MULTIARCH_DIRNAME
+If @code{MULTIARCH_DIRNAME} is used, this variable specifies the
+multiarch name for this configuration.  For multiarch enabled
+configurations it is used to search libraries and crt files in
+@file{/lib/@var{multiarch}} and @file{/usr/lib/@var{multiarch}}, and
+system header files in @file{/usr/include/@var{multiarch}}.
+@code{MULTIARCH_DIRNAME} is not used for multilib enabled
+configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead.
+
 @findex NATIVE_SYSTEM_HEADER_DIR
 @item NATIVE_SYSTEM_HEADER_DIR
 If the default location for system headers is not @file{/usr/include},
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 177846)
+++ gcc/doc/invoke.texi (working copy)
@@ -5937,6 +5937,11 @@
 @file{../lib32}, or if OS libraries are present in @file{lib/@var{subdir}}
 subdirectories it prints e.g.@: @file{amd64}, @file{sparcv9} or @file{ev6}.
 
+@item -print-multiarch
+@opindex print-multiarch
+Print the path to OS libraries for the selected multiarch,
+relative to some @file{lib} subdirectory.
+
 @item -print-prog-name=@var{program}
 @opindex print-prog-name
 Like @option

Re: [patch] support for multiarch systems

[Matthias Klose]

On 08/20/2011 10:39 PM, Joseph S. Myers wrote:
> On Sat, 20 Aug 2011, Matthias Klose wrote:
> 
>> The multiarch triplets are defined in the target specific tmake files, and
>> provided for all known existing multiarch implementations (currently Debian,
>> Ubuntu and derivatives).  For non-multilib'd configurations, the triplet is
> 
> Is there a specification somewhere of what the various triplets mean?

there is
https://lists.linux-foundation.org/pipermail/lsb-discuss/2011-February/006674.html
http://wiki.debian.org/Multiarch/Tuples

but the documentation is not up to date. The tuples in use are:

$ for a in alpha amd64 armel armhf hppa i386 ia64 mips mipsel powerpc powerpcspe
ppc64 s390 s390x sh4 sparc sparc64 kfreebsd-i386 kfreebsd-amd64 hurd-i386; do
dpkg-architecture -a$a -qDEB_HOST_MULTIARCH 2>/dev/null; done
alpha-linux-gnu
x86_64-linux-gnu
arm-linux-gnueabi
arm-linux-gnueabihf
hppa-linux-gnu
i386-linux-gnu
ia64-linux-gnu
mips-linux-gnu
mipsel-linux-gnu
powerpc-linux-gnu
powerpc-linux-gnuspe
powerpc64-linux-gnu
s390-linux-gnu
s390x-linux-gnu
sh4-linux-gnu
sparc-linux-gnu
sparc64-linux-gnu
i386-kfreebsd-gnu
x86_64-kfreebsd-gnu
i386-gnu

>> defined in MULTIARCH_DIRNAME, for multilib'd configurations each directory in
>> MULTILIB_OSDIRNAMES gets an multiarch directory associated, separated by a 
>> colon
> 
> I don't see any documentation in fragments.texi for this 
> (MULTIARCH_DIRNAME is new so certainly needs documenting, even if you get 
> away with not adding to the nonexistent documentation for 
> MULTILIB_OSDIRNAMES (PR 25508)).

well, I hope I get away with copying it from genmultilib without closing the
report ;)

>> (e.g. ../lib:x86_64-linux-gnu).  The multiarch names are as used by Debian, 
>> the
> 
> Does this work with the "gccdir=osdir" and "gccdir=!osdir" cases before 
> the colon?

amd64 is configured this way, and I don't handle the !osdir case other than for
the multilib osdir.

>> mips names go back to a discussion from 2006 [3] to match thee, ones for 
>> glibc.
> 
> For x86, shouldn't a name be allocated for x32?

maybe, but I didn't see a port yet.

> For m68k, classic m68k and ColdFire have incompatible ABIs.  So you need 
> to define what m68k-linux-gnu means of the two ABIs.  Unfortunately 
> building for ColdFire has been broken for some time, since 
>  (this ought to 
> have been dependent on the --with-arch configurey).

it's the classic m68k. yes, it has to be defined.

> For 32-bit Power, hard-float and soft-float ABIs are incompatible.  
> Furthermore, the soft-float ABI is used at function-calling level for 
> e500v1 and e500v2 - but there are differences in the details of the glibc 
> symbols exported (and at least the fenv.h ABI is incompatible between 
> soft-float and e500).  So actually there are four variants at the glibc 
> level.  You need to define what powerpc-linux-gnu means and avoid it being 
> used for anything incompatible.

same here. powerpc-linux-gnu is the hard-float one. Debian has an e500 port in
development which currently uses powerpc-linux-gnuspe

> For MIPS, the hard-float and soft-float ABIs are incompatible.  So you 
> need twelve triplets, not six.

yes. but I didn't see a soft-float mips port yet.

> For ARM, you have a ChangeLog entry with no corresponding patch.  You need 
> to distinguish big and little endian; old ABI, EABI soft-float ABI and 
> EABI hard-float ABI (six triplets).

ok, added. Debian has little endian ports only. I see that dpkg treats the
obsolete armeb port as armeb-linux-gnu.

> Not all of those variants necessarily are configurable in a multilib 
> configuration in the FSF tree (the e500 variants can be achieved with 
> powerpc-linux-gnuspe triplets, for example, but those don't have other 
> multilibs).  So maybe some of the names won't actually appear in the FSF 
> sources - but you still need to define the semantics of the names that do 
> appear (whether in the manuals, on the GCC wiki or elsewhere) and 
> preferably have somewhere to define semantics for the names not used in 
> multilib configurations in FSF GCC.

For now, the multiarch documentation should be consolidated; I would like to add
a link from the FCC wiki to this documentation mentioned above.

  Matthias

Re: [patch] support for multiarch systems

[Matthias Klose]

On 08/20/2011 10:07 PM, Jakub Jelinek wrote:
> On Sat, Aug 20, 2011 at 09:51:33PM +0200, Matthias Klose wrote:
>> Tested on non-multilib'd and multilib'd systems, both native and cross 
>> builds.
>> Ok for the trunk?
> 
> I don't think we want to do this unconditionally, we already search way too
> many directories by default.  This is a Debian/Ubuntu specific setup, I
> don't think many others are going to use such a setup.
> So, IMHO you should make it configure time selectable whether those extra
> dirs are searched or not.  And by default either don't enable it, or enable
> it only on Debian/Ubuntu.

Ok, I made it conditional, enabled only if the crti.o file is found in a
multiarch path.

Re: [patch] support for multiarch systems

[Joseph S. Myers]

On Sat, 20 Aug 2011, Matthias Klose wrote:

> The multiarch triplets are defined in the target specific tmake files, and
> provided for all known existing multiarch implementations (currently Debian,
> Ubuntu and derivatives).  For non-multilib'd configurations, the triplet is

Is there a specification somewhere of what the various triplets mean?

> defined in MULTIARCH_DIRNAME, for multilib'd configurations each directory in
> MULTILIB_OSDIRNAMES gets an multiarch directory associated, separated by a 
> colon

I don't see any documentation in fragments.texi for this 
(MULTIARCH_DIRNAME is new so certainly needs documenting, even if you get 
away with not adding to the nonexistent documentation for 
MULTILIB_OSDIRNAMES (PR 25508)).

> (e.g. ../lib:x86_64-linux-gnu).  The multiarch names are as used by Debian, 
> the

Does this work with the "gccdir=osdir" and "gccdir=!osdir" cases before 
the colon?

> mips names go back to a discussion from 2006 [3] to match the ones for glibc.

For x86, shouldn't a name be allocated for x32?

For m68k, classic m68k and ColdFire have incompatible ABIs.  So you need 
to define what m68k-linux-gnu means of the two ABIs.  Unfortunately 
building for ColdFire has been broken for some time, since 
 (this ought to 
have been dependent on the --with-arch configurey).

For 32-bit Power, hard-float and soft-float ABIs are incompatible.  
Furthermore, the soft-float ABI is used at function-calling level for 
e500v1 and e500v2 - but there are differences in the details of the glibc 
symbols exported (and at least the fenv.h ABI is incompatible between 
soft-float and e500).  So actually there are four variants at the glibc 
level.  You need to define what powerpc-linux-gnu means and avoid it being 
used for anything incompatible.

For MIPS, the hard-float and soft-float ABIs are incompatible.  So you 
need twelve triplets, not six.

For ARM, you have a ChangeLog entry with no corresponding patch.  You need 
to distinguish big and little endian; old ABI, EABI soft-float ABI and 
EABI hard-float ABI (six triplets).

Not all of those variants necessarily are configurable in a multilib 
configuration in the FSF tree (the e500 variants can be achieved with 
powerpc-linux-gnuspe triplets, for example, but those don't have other 
multilibs).  So maybe some of the names won't actually appear in the FSF 
sources - but you still need to define the semantics of the names that do 
appear (whether in the manuals, on the GCC wiki or elsewhere) and 
preferably have somewhere to define semantics for the names not used in 
multilib configurations in FSF GCC.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [patch] support for multiarch systems

[Jakub Jelinek]

On Sat, Aug 20, 2011 at 09:51:33PM +0200, Matthias Klose wrote:
> Tested on non-multilib'd and multilib'd systems, both native and cross builds.
> Ok for the trunk?

I don't think we want to do this unconditionally, we already search way too
many directories by default.  This is a Debian/Ubuntu specific setup, I
don't think many others are going to use such a setup.
So, IMHO you should make it configure time selectable whether those extra
dirs are searched or not.  And by default either don't enable it, or enable
it only on Debian/Ubuntu.

Jakub

[patch] support for multiarch systems

[Matthias Klose]

Multiarch [1] is the term being used to refer to the capability of a system to
install and run applications of multiple different binary targets on the same
system.  The idea and name of multiarch dates back to 2004/2005 [2] (to be
confused with multiarch in glibc).

Multiarch defines new system directories for headers and libraries/object files:

  /usr/include/
  /lib/
  /usr/lib/

  /usr/local/include/
  /usr/local/lib/

The attached patch

 - searches for multiarch subdirectories in the list of
   startfile_prefixes
 - passes the option -imultiarch to the compiler binaries
 - the compiler binaries add the multiarch include paths
   to the system include path.
 - adds a driver option -print-multiarch

The multiarch triplets are defined in the target specific tmake files, and
provided for all known existing multiarch implementations (currently Debian,
Ubuntu and derivatives).  For non-multilib'd configurations, the triplet is
defined in MULTIARCH_DIRNAME, for multilib'd configurations each directory in
MULTILIB_OSDIRNAMES gets an multiarch directory associated, separated by a colon
(e.g. ../lib:x86_64-linux-gnu).  The multiarch names are as used by Debian, the
mips names go back to a discussion from 2006 [3] to match the ones for glibc.

Tested on non-multilib'd and multilib'd systems, both native and cross builds.
Ok for the trunk?

  Matthias

[1] http://wiki.debian.org/Multiarch
[2] http://debconf5.debconf.org/comas/general/proposals/27.html
[3] http://lists.debian.org/debian-mips/2006/03/msg4.html


2011-08-20  Matthias Klose  

* doc/invoke.texi: Document -print-multiarch.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
* genmultilib: Add new option for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux64: Likewise.
* config/powerpc/t-linux64: Likewise.
* config/i386/t-linux64: Likewise.
* config/mips/t-linux64: Likewise.
* config/alpha/t-linux: Define MULTIARCH_DIRNAME.
* config/arm/t-linux: Likewise.
* config/i386/t-linux: Likewise.
* config/pa/t-linux: Likewise.
* config/sparc/t-linux: Likewise.
* config/ia64/t-glibc: Define MULTIARCH_DIRNAME for linux target.
* gcc/config/i386/t-gnu: New, Define MULTIARCH_DIRNAME.
* gcc/config/i386/t-kfreebsd: New, Define MULTIARCH_DIRNAME and
MULTILIB_OSDIRNAMES.



Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 177846)
+++ gcc/doc/invoke.texi (working copy)
@@ -5937,6 +5937,11 @@
 @file{../lib32}, or if OS libraries are present in @file{lib/@var{subdir}}
 subdirectories it prints e.g.@: @file{amd64}, @file{sparcv9} or @file{ev6}.
 
+@item -print-multiarch
+@opindex print-multiarch
+Print the path to OS libraries for the selected multiarch,
+relative to some @file{lib} subdirectory.
+
 @item -print-prog-name=@var{program}
 @opindex print-prog-name
 Like @option{-print-file-name}, but searches for a program such as @samp{cpp}.
Index: gcc/incpath.c
===
--- gcc/incpath.c   (revision 177846)
+++ gcc/incpath.c   (working copy)
@@ -150,8 +150,14 @@
  if (!filename_ncmp (p->fname, cpp_GCC_INCLUDE_DIR, len))
{
  char *str = concat (iprefix, p->fname + len, NULL);
- if (p->multilib && imultilib)
+ if (p->multilib == 1 && imultilib)
str = concat (str, dir_separator_str, imultilib, NULL);
+ else if (p->multilib == 2)
+   {
+ if (!imultiarch)
+   continue;
+ str = concat (str, dir_separator_str, imultiarch, NULL);
+   }
  add_path (str, SYSTEM, p->cxx_aware, false);
}
}
@@ -195,8 +201,14 @@
  else
str = update_path (p->fname, p->component);
 
- if (p->multilib && imultilib)
+ if (p->multilib == 1 && imultilib)
str = concat (str, dir_separator_str, imultilib, NULL);
+