Re: [patch] support for multiarch systems
Hi!
On Mon, 25 Jun 2012 18:19:26 +0200, Matthias Klose d...@ubuntu.com 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 d...@ubuntu.com
* 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
http://news.gmane.org/find-root.php?message_id=%3C87zk94cg1h.fsf%40schwinge.name%3E
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
On 28.06.2012 12:01, Thomas Schwinge wrote:
Hi!
On Mon, 25 Jun 2012 18:19:26 +0200, Matthias Klose d...@ubuntu.com
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 d...@ubuntu.com
* 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
http://news.gmane.org/find-root.php?message_id=%3C87zk94cg1h.fsf%40schwinge.name%3E
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
Hi!
On Thu, 28 Jun 2012 12:42:23 +0200, Matthias Klose d...@ubuntu.com wrote:
On 28.06.2012 12:01, Thomas Schwinge wrote:
On Mon, 25 Jun 2012 18:19:26 +0200, Matthias Klose d...@ubuntu.com
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 d...@ubuntu.com
* 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
http://news.gmane.org/find-root.php?message_id=%3C87zk94cg1h.fsf%40schwinge.name%3E
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 i[34567]86-*-linux* | x86_64-*-linux* (tmake_file):
Include i386/t-linux.
i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu (tmake_file):
Include i386/t-kfreebsd.
i[34567]86-*-gnu* (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
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 d...@ubuntu.com
* 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)
+
Re: [patch] support for multiarch systems
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
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 d...@ubuntu.com
* 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
Hi!
On Sat, 19 May 2012 18:05:30 +0200, I wrote:
On Wed, 09 May 2012 02:38:11 +0200, Matthias Klose d...@ubuntu.com 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 i[34567]86-*-linux* | x86_64-*-linux* (tmake_file):
Include i386/t-linux.
i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu (tmake_file):
Include i386/t-kfreebsd.
i[34567]86-*-gnu* (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
Hi!
On Wed, 09 May 2012 02:38:11 +0200, Matthias Klose d...@ubuntu.com 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
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
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
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.
+The multiarch tuples are defined
+in @uref{http://wiki.debian.org/Multiarch/Tuples}.
Is this needed? Aren't they defined
Re: [patch] support for multiarch systems
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
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
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
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
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
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 - /dev/null 21 | grep ^LIBRARY_PATH Matthias
Re: [patch] support for multiarch systems
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
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 d...@ubuntu.com * 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=dir Set dir to be the default plugin directory +imultiarch +Common Joined Separate RejectDriver Var(imultiarch) Init(0) +-imultiarch dir Set dir 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@
Re: [patch] support for multiarch systems
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 d...@ubuntu.com
* 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=dir Set dir to be the default plugin directory
+imultiarch
+Common Joined Separate RejectDriver Var(imultiarch) Init(0)
+-imultiarch dir Set dir 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)
+
Re: [patch] support for multiarch systems
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
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
Hi!
On Sun, 21 Aug 2011 02:14:10 +0200, Matthias Klose d...@ubuntu.com 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 i[34567]86-*-kfreebsd*-gnu, x86_64-*-kfreebsd*-gnu
i[34567]86-*-gnu*: 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
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
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
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
Re: [patch] support for multiarch systems
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 http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01845.html (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
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
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 http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01845.html (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
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 d...@ubuntu.com
* 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
Re: [patch] support for multiarch systems
On Sat, Aug 20, 2011 at 5:11 PM, Matthias Klose d...@ubuntu.com 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
