[ CCing Matthias, as I'd like your opinion on my proposed solution
involving some Debian gcc changes. ]
Hi!
On Thu, 2011-02-17 at 12:27:30 +0100, Loïc Minier wrote:
> Trying to kick the dust a bit as having the triplet "in the air" is
> kind of an unhappy situation for armhf :-)
I think it's fair to assume several of you have already peeked into the
notes I circulated on IRC the other day, :) I'm reincluding them here
although slightly redacted and extended, for the benefit of the rest
of the people. I'll still reply to specific points you rised below.
GNU triplets
------------
* gcc upstream claims GNU triplets do not fully encode ABI:
- Thus cannot be used properly to map deb arch ←→ GNU triplet.
- Thus cannot be used for multiarch paths.
- Thus cannot be used for default cross-toolchains sharing GNU triplet.
- Thus we'd need yet another ABI encoding and mapping for multiarch
and dpkg arches, instead of being able to just use GNU triplets.
The one being currently proposed can be found at
<http://wiki.debian.org/Multiarch/Tuples>.
* But the GNU triplets have always encoded the ABI, it's even
extremely explicit in some cases, for example with the arm EABI,
executable formats (elf, aout, ecoff, etc) or stuff like
powerpc-*-eabispe* or powerpc-*-eabialtivec* (supported by gcc
upstream).
* And we already use GNU triplets for powerpcspe (powerpc-linux-gnuspe)
and lpia (i386-linux-gnulp) arches, and these do not need gcc upstream
support as are handled transparently by the -gnu* patterns, and any
differing ABI options are selected by the Debian gcc packaging.
* There's other gcc options which can change the ABI of the default
compiler besides the --with-float one, like --with-long-double-128,
etc, and still they are not a problem mainly for two reasons:
1) In case they do not need to coexist, they can be handled like
other transitions, like it was done in Debian, by renaming
shared library packages or with versioned symbols and handling
both ABIs at the same time.
2) No one seems to have needed to create coexisting default toolchains
with diverging ABI options at the same time until now, or they have
done so privately.
* I think it's important to be able to consistently support co-installing
different default cross-compilers for different ABIs which would
otherwise share the same triplet. And while we could avoid the problem
for multiarch libraries co-installations by using the multiarch tuples,
we would not be able to avoid it for the cross-compilers.
* The assumption that each GNU triplet denotes a different ABI is so
entrenched in the GNU build system, that we have things like the
following all over the place to properly support cross-building:
,---
ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
confflags += --build $(DEB_HOST_GNU_TYPE)
else
confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
endif
`---
This would not hold true any longer if we didn't use a unique triplet
per arch, and would thus break in quite annoying ways. For further
details why that's needed check the autotools-dev section
“Calling GNU configure properly” in its README.Debian.
* Ignoring the bi-directional 1:1 mapping would be a PITA, as it implies
not being able to automatically bootstrap dpkg on a new port or
dpkg package builds on foreign distros. The former is annoying but not
done frequently, the latter is going to be a problem for each non-dpkg
based distribution, as they'll have to bootstrap dpkg on each arch
where dpkg is built anew. It ends up being a matter of off-loading the
knowledge of the arch and build system from the dpkg/gcc combo to the
porters/maintainers, which seems rather unappealing.
* Other packaging systems seem to not have made quite the same assumption
about the GNU triplet as dpkg/Debian does. Gentoo's portage at least
relies on the GNU triplet being unique per different arch as itseems to
be using it on the path somehow. rpm and conary for example use uname
which is not enough by itself, and quite unsatisfactory as it's lacking
quite a bit of the ABI information, which probably has not presented as
a problem for them as they do not have the amount of supported arches
as Debian does, neither do they seem to have the same amount of
mixes/convinations we do. So the other approaches seem to be actually
inferior.
* The remaining problem at least for multiarch is the use of more
specialized cpu names for the i386 triplets, i486-linux-gnu on Debian,
which might change depending on the base instruction set to support,
for example i686-linux-gnu on Ubuntu.
Due to #611741, it already crossed my mind (but removed it from the
list of solutions before sending the reply as at the time it seemed
slighly preposterous just to fix the divergence with Ubuntu) that we
should switch back our i386 arch to use i386 as the base cpu name for
the triplet (i386-linux-gnu) in the same way we use it in other
arches, like on arm where we use arm-linux-gnu instead of something
like armv4tel-linux-gnueabi, for example. (I mentioned this already to
Steve and Raphaël on some private conversation.)
Solution(s)
-----------
So while some of the previous points _could_ be considered corner-cases,
there are several of them piling up, which work just fine with our (and
GNU build system) current assumptions, and breaking them seems
gratuituous and way worse than not doing it, as it adds future confusion,
breakage and complexity, instead of the extremely “simple” and more
correct solution (in contrast to the claimed dpkg lameness/limitation,
which I disagree with, and I think I've proven incorrect above) of just
using a new triplet.
- Use additional pre-processor macros for armhf, inccurs an additional
pre-processor call for the arm arches. It implies the Debian arches
cannot be fully retrieved w/o a cross-compiler for each of the arches
lacking information, which means we lose the univeral bi-directional
mapping.
This one is a no go.
- Abuse the vendor field, a hack upstream does not like either, although
strangely enough they seem to prefer it instead of a proper triplet.
Although viable, I don't really see the point, we might as well just
do the right thing and use a proper triplet then.
+ Just use a new triplet arm-*-*-gnueabihf or whatever in a similar vein
as our own -gnulp and -gnuspe.
Would not need to be explicitly supported by gcc upstream to perform
the automatic selection of the ABI based on the triplet for different
variants, which seems to be the biggest reason they have against it.
This should be satisfactory for upstream as the magic will be kept
in the Debian packaging, and they can be kept oblivious of it.
Package build systems might be matching against stuff like
arm*-*-linux-gnueabi, so it might require changes to match on -gnueabi*
instead, but is more immediate, and not like propagating config.guess
all over the place, which we should not need as debian/rules should
be passing --build to configure anyway, and config.sub can already
canonicalize something like arm-linux-gnueabihf by way of the current
patterns.
Switch also i486-linux-gnu (Debian) and i686-linux-gnu (Ubuntu) to
simply i386-linux-gnu (but still preserving their respective cpu
tunnings). This also fixes this inconsistency in the i386 arch.
So Matthias would you be amenable to including something like the
attached patch to Debian gcc (regardless of upstream accepting it,
although the patch is pretty minimal and non-intrusive, which would
seem to have good chances of being accepted there)?
What about switching the triplet for i386, I could prepare patches
for that if you want (I think it's a one-liner though)?
Konstantinos, would you be willing test such patch with an accompanying
triplet in dpkg (patch attached too)? If you don't like
arm-linux-gnueabihf, then something like arm-linux-gnueabivfp or
whatever you want, I don't think I particularly care much, it would
need to be prefixed arm-linux-gnueabi though so that the matches work
transparently.
Beware, both patches completely untested!
> On Wed, Sep 08, 2010, Guillem Jover wrote:
> > We currently need something like this in dpkg-dev because the mappings
> > need to be bidirectional, as dpkg-dev needs to be able to convert
> > from GNU triplet to Debian architecture and the other way around.
> >
> > Steve wondered why this is the case, and that's because for
> > cross-compiling purposes dpkg-architecture infers the host architecture
> > from the CC environment variable through the -dumpmachine option.
> > Chaning this is possible but, would break a current way of
> > cross-compiling which has been around for a long time.
>
> So this use case is "CC=arm-linux-gnueabi-gcc dpkg-buildpackage" and it
> just guesses the -a flag that you should have set?
That and for automatic bootstrapping purposes too.
> > The toolchain has the same triplet for binary incompatible producing
> > objects, which seems like a bug/misfeature to me, and that's one of
> > the assumptions dpkg-dev has relied on, in the same way as multiarch
> > when deciding to use the triplet as a unique token for the installation
> > directories.
>
> You describe this as a bug/misfeature, that might be true but I don't
> think we can challenge this usage of triplets in the upstream
> toolchain, and multiarch is moving to having its own tuples instead now
> (http://wiki.debian.org/Multiarch/Tuples).
Oh, but I think I just did. :) Also given the above I don't think it
makes sense to invent a new set of tuples, the triplets should work
just fine. In addition those tuples end up relying partly on the
definition of the ABI the default gcc has for a given target, which
should not change incompatibly for a given Debian architecture, or we
are screwed anyway. So I don't see that it buys us much.
> > This also causes issue with not being able to have installed two
> > cross-toolchains for say armel and armhf as they share triplet,
> > although you can use the armel toolchain with few options to build for
> > armhf, but then you'd need to specify those as part of the CC variable.
>
> Even if we could co-install them, I'm not sure how
> /some-armel-path/arm-linux-gnueabi-gcc and
> /some-armhf-path/arm-linux-gnueabi-gcc could helpfully be installed on
> the same system :-/
Well for cross-toolchains you have them in the PATH, and they just get
prefixed with the triplet so you'd end up with something like:
/usr/bin/arm-linux-gnueabi-gcc-4.4
/usr/lib/gcc/arm-linux-gnueabi/4.4.5
and
/usr/bin/arm-linux-gnueabihf-gcc-4.4
/usr/lib/gcc/arm-linux-gnueabihf/4.4.5
which work just fine, as they should.
> It's a real limitation of the upstream toolchain.
Not really, it's only a limitation if the same triplet is used for
incompatible ABIs.
> > Also that also happens with biarch, you can produce i386 binaries from
> > an x86_64 toolchain, yet they both have their own triplet.
>
> Yes but x86 goes to the other extreme, with separate triplets for
> compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
> triplet is not a good ABI specifier.
Sure, but as mentioned above, I'm now convinced the correct solution is
to switch back to i386-linux-gnu.
> > Anyway, ideally I'd rather see this addressed by giving armhf a real
> > triplet, which would also make multiarch life way easier as there'd not
> > be any need to define an artificial set of neutral architecture names
> > to be able to place objects in the file system. But if this is not going
> > to happen, and thus the assumptions dpkg-dev is making have been just
> > wrong, then I'd rather drop the bidirectional mappings, and be done
> > with it. This will need careful consideration though, as it's breaking
> > a current interface, but something that could be done for dpkg 1.16.x.
>
> Having a separate triplet (not using the vendor field) like e.g. lpia
> would mean a lot of pain IMO, and we'd have to fix many packages to
> cope with it, including reaching out to upstream etc. It was pain for
> lpia for sure.
If we have to fix lots of packages that means they are already buggy,
at least for the packaging bits, the packaging should not generally
be matching against the GNU triplets. For their upstream build systems
that might possibly mean changing from *-gnueabi to *-gnueabi*, but I
doubt there are many upstream build systems matching against -gnueabi
at all? Most should be matching against *-gnu* if at all.
> We could have an additional set of preprocessor macros which dpkg
> checks for to decide which Debian architecture we're talking about; the
> the would only be done if there is more than one architecture using the
> same triplet in dpkg tables. This alone is a bit fragile though, as it
> means that if a new ABI is introduced to an existing triplet and is not
> immediately added as a new dpkg architecture, then people might be
> picking the wrong dpkg architecture when using a toolchain defaulting
> to thenew ABI.
As stated above, it does not solve many of the stated problems, so a no
go, also as a counter example, arm EABI actually uses such a macro to
define its own triplet (see config.guess).
> I wonder whether it would be a good idea to use multiarch tuples
> internally; dpkg would still have to map to/from GNU triplets, but it
> would force implementors to think about their ABI. I am not sure how
> we can ensure that we've mapped to the right tuple though. Neither am
> I sure that the multiarch tuples are frozen already, so it might be too
> early for that either.
Given the above conclusion, that the GNU triplets must be already unique
per arch and cannot arbitrarily change ABI or it'd break stuff, I don't
really see the point in switching the internal representation, because I
don't really see the point in the multiarch tuples, when the GNU triplets
seems to do the job just fine (modulo the armhf and i386 issues, which we
should just fix).
thanks,
guillem
diff --git a/configure b/configure
index 501c6ff..0bdf69a 100755
--- a/configure
+++ b/configure
@@ -3236,7 +3236,7 @@ case "${target}" in
noconfigdirs="$noconfigdirs target-libffi target-qthreads"
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-gnueabi*)
noconfigdirs="$noconfigdirs target-qthreads"
case ${with_newlib} in
no) noconfigdirs="$noconfigdirs target-newlib target-libgloss"
diff --git a/configure.ac b/configure.ac
index 9121d65..89514f5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -682,7 +682,7 @@ case "${target}" in
noconfigdirs="$noconfigdirs target-libffi target-qthreads"
libgloss_dir=arm
;;
- arm*-*-linux-gnueabi)
+ arm*-*-linux-gnueabi*)
noconfigdirs="$noconfigdirs target-qthreads"
case ${with_newlib} in
no) noconfigdirs="$noconfigdirs target-newlib target-libgloss"
diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index b64ba55..642b317 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -1841,7 +1841,7 @@ ifeq ($(strip $(filter-out powerpc% linux%,$(arch) $(osys))),)
LIBRARY_VERSION := $(LIB_VERSION)
endif
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 4,$(targ)))),)
+ifeq ($(strip $(filter-out arm% linux-gnueabi%,$(arch) $(osys)-$(word 4,$(targ)))),)
LIBGNAT_TARGET_PAIRS = \
a-intnam.ads<a-intnam-linux.ads \
s-inmaop.adb<s-inmaop-posix.adb \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 54b822e..1a47343 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -820,13 +820,13 @@ arm*-*-linux*) # ARM GNU/Linux with ELF
esac
tmake_file="${tmake_file} t-linux arm/t-arm"
case ${target} in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
tm_file="$tm_file arm/bpabi.h arm/linux-eabi.h"
tm_file="$tm_file ../../libgcc/config/arm/bpabi-lib.h"
tmake_file="$tmake_file arm/t-arm-elf arm/t-bpabi arm/t-linux-eabi t-slibgcc-libgcc"
# Define multilib configuration for arm-linux-androideabi.
case ${target} in
- *-androideabi)
+ *-androideabi*)
tmake_file="$tmake_file arm/t-linux-androideabi"
;;
esac
@@ -848,7 +848,7 @@ arm*-*-uclinux*) # ARM ucLinux
tm_file="dbxelf.h elfos.h arm/unknown-elf.h arm/elf.h arm/linux-gas.h arm/uclinux-elf.h glibc-stdint.h"
tmake_file="arm/t-arm arm/t-arm-elf"
case ${target} in
- arm*-*-uclinux*eabi)
+ arm*-*-uclinux*eabi*)
tm_file="$tm_file arm/bpabi.h arm/uclinux-eabi.h"
tm_file="$tm_file ../../libgcc/config/arm/bpabi-lib.h"
tmake_file="$tmake_file arm/t-bpabi"
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 02cb7ac..fbd5e78 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3219,7 +3219,7 @@ proc check_effective_target_sync_int_long { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
- || [istarget arm*-*-linux-gnueabi]
+ || [istarget arm*-*-linux-gnueabi*]
|| [istarget bfin*-*linux*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
@@ -3250,7 +3250,7 @@ proc check_effective_target_sync_char_short { } {
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
- || [istarget arm*-*-linux-gnueabi]
+ || [istarget arm*-*-linux-gnueabi*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
diff --git a/libjava/configure b/libjava/configure
index f79e53b..2084c68 100755
--- a/libjava/configure
+++ b/libjava/configure
@@ -20527,7 +20527,7 @@ case "${host}" in
# on Darwin -single_module speeds up loading of the dynamic libraries.
extra_ldflags_libjava=-Wl,-single_module
;;
-arm*linux*eabi)
+arm*linux*eabi*)
# Some of the ARM unwinder code is actually in libstdc++. We
# could in principle replicate it in libgcj, but it's better to
# have a dependency on libstdc++.
diff --git a/libjava/configure.ac b/libjava/configure.ac
index 8187eec..8d56a79 100644
--- a/libjava/configure.ac
+++ b/libjava/configure.ac
@@ -919,7 +919,7 @@ case "${host}" in
# on Darwin -single_module speeds up loading of the dynamic libraries.
extra_ldflags_libjava=-Wl,-single_module
;;
-arm*linux*eabi)
+arm*linux*eabi*)
# Some of the ARM unwinder code is actually in libstdc++. We
# could in principle replicate it in libgcj, but it's better to
# have a dependency on libstdc++.
diff --git a/libstdc++-v3/configure.host b/libstdc++-v3/configure.host
index e29404c..a2e58a9 100644
--- a/libstdc++-v3/configure.host
+++ b/libstdc++-v3/configure.host
@@ -322,7 +322,7 @@ case "${host}" in
fi
esac
case "${host}" in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
port_specific_symbol_files="\$(srcdir)/../config/os/gnu-linux/arm-eabi-extra.ver"
;;
esac
diff --git a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
index cb40b7b..ae63bd8 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
@@ -1,5 +1,5 @@
// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums" }
-// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums -Wl,--no-enum-size-warning" { target arm*-*-linux*eabi } }
+// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums -Wl,--no-enum-size-warning" { target arm*-*-linux*eabi* } }
// 2007-05-03 Benjamin Kosnik <b...@redhat.com>
//
diff --git a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
index d71c012..1b9f6c7 100644
--- a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
+++ b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
@@ -1,5 +1,5 @@
// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums" }
-// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums -Wl,--no-enum-size-warning" { target arm*-*-linux*eabi } }
+// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums -Wl,--no-enum-size-warning" { target arm*-*-linux*eabi* } }
// 2007-05-03 Benjamin Kosnik <b...@redhat.com>
//
diff --git a/ostable b/ostable
index 17b7581..4c81abe 100644
--- a/ostable
+++ b/ostable
@@ -16,6 +16,7 @@
# <Debian name> <GNU name> <config.guess regex>
uclibceabi-linux linux-uclibceabi linux[^-]*-uclibceabi
uclibc-linux linux-uclibc linux[^-]*-uclibc
+gnueabihf-linux linux-gnueabihf linux[^-]*-gnueabihf
gnueabi-linux linux-gnueabi linux[^-]*-gnueabi
gnuspe-linux linux-gnuspe linux[^-]*-gnuspe
gnulp-linux linux-gnulp linux[^-]*-gnulp
diff --git a/triplettable b/triplettable
index 3e076e2..f47d68c 100644
--- a/triplettable
+++ b/triplettable
@@ -5,6 +5,7 @@
# <Debian triplet> <Debian arch>
uclibceabi-linux-arm uclibc-linux-armel
uclibc-linux-<cpu> uclibc-linux-<cpu>
+gnueabihf-linux-arm armhf
gnueabi-linux-arm armel
gnuspe-linux-powerpc powerpcspe
gnulp-linux-i386 lpia
