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

Re: Bug#594179: dpkg armhf patch acceptance status?

[ CCing Matthias, as I'd like your opinion on my proposed solution
  involving some Debian gcc changes. ]


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

* 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

* 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:

    confflags += --build $(DEB_HOST_GNU_TYPE)
    confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)

  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

* 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.)


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

  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

  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

  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:




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).

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"
-  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"
-  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))),)
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word 4,$(targ)))),)
+ifeq ($(strip $(filter-out arm% linux-gnueabi%,$(arch) $(osys)-$(word 4,$(targ)))),)
   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
 	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"
@@ -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.
     # 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.
     # 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
     case "${host}" in
-      arm*-*-linux-*eabi)
+      arm*-*-linux-*eabi*)
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  <bkoz@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  <bkoz@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

Reply to: