On 21/02/11 10:12, Guillem Jover wrote:
This was already discussed in this list some time ago [0]. But it came
up again when restarting the discussion for the proposed new armhf port
for Debian.
[0]http://gcc.gnu.org/ml/gcc/2010-07/msg00179.html
My arguments for why a distinct triplet is
Here is an amended patch that handles Ada as EABI-only on ARM.
Are there any other comments on the appropriateness of this globbing change?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the
Hi!
On Mon, 2011-02-28 at 16:12:32 -0800, Steve Langasek wrote:
Here is an amended patch that handles Ada as EABI-only on ARM.
diff --git a/gcc/ada/gcc-interface/Makefile.in
b/gcc/ada/gcc-interface/Makefile.in
index b64ba55..7559efb 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++
Guillem Jover writes:
On Mon, 2011-02-21 at 17:59:06 +, Joseph S. Myers wrote:
On Mon, 21 Feb 2011, Guillem Jover wrote:
if you'd consider accepting something ressembling the attached patch
A pre-existing condition, but in general where the code you're changing
hardcodes
Hi!
This was already discussed in this list some time ago [0]. But it came
up again when restarting the discussion for the proposed new armhf port
for Debian.
[0] http://gcc.gnu.org/ml/gcc/2010-07/msg00179.html
My arguments for why a distinct triplet is needed can be found in [1],
it's a big
On Mon, 21 Feb 2011, Guillem Jover wrote:
if you'd consider accepting something ressembling the attached patch
A pre-existing condition, but in general where the code you're changing
hardcodes gnu that's wrong - arm*-*-linux-uclibceabi is also meant to be
valid. So if you allow a suffix
On Mon, 2011-02-21 at 17:59:06 +, Joseph S. Myers wrote:
On Mon, 21 Feb 2011, Guillem Jover wrote:
if you'd consider accepting something ressembling the attached patch
A pre-existing condition, but in general where the code you're changing
hardcodes gnu that's wrong -
On 12/07/10 14:25, Andrew Stubbs wrote:
This means that we need to choose a name for it. Obviously, it's better
if it's an official name, so I want to discuss it here. I'm aware that
there is some bikeshedding to do here, but it's better it gets done
before anybody gets stuck with something
Hi All,
Both Linaro and Debian are considering supporting the ARM hard-float
variant of the EABI, at least as an unofficial port. This ABI is not
compatible with the gnueabi currently in use for most ARM Linux distros,
but has a number of performance advantages.
This means that we need to
Quoting Andrew Stubbs a...@codesourcery.com:
Hi All,
Hi, long time no see...
So here are my suggestions:
arm-linux-gnueabihf
or maybe
arm-linux-gnueabi-hf
I don't like the inflation of dashes - it breaks scripts that want to
parse the host triplet / quadruplet (IMO having a
On Mon, 2010-07-12 at 10:23 -0400, Joern Rennecke wrote:
Quoting Andrew Stubbs a...@codesourcery.com:
Hi All,
Hi, long time no see...
So here are my suggestions:
arm-linux-gnueabihf
or maybe
arm-linux-gnueabi-hf
I don't like the inflation of dashes - it breaks
Both Linaro and Debian are considering supporting the ARM hard-float
variant of the EABI, at least as an unofficial port. This ABI is not
compatible with the gnueabi currently in use for most ARM Linux distros,
but has a number of performance advantages.
This means that we need to choose a
On Mon, 2010-07-12 at 16:03 +0100, Paul Brook wrote:
Both Linaro and Debian are considering supporting the ARM hard-float
variant of the EABI, at least as an unofficial port. This ABI is not
compatible with the gnueabi currently in use for most ARM Linux distros,
but has a number of
On 12/07/10 15:51, Richard Earnshaw wrote:
if we could turn back the clock, I'd even prefer
arm-linux_gnu_hf_eabi to get back to a single '-'-parsed OS string, but
the linux-gnu stuff is now entrenched, so trying to change back would only
cause more disruption.
quadruplets, quintuplets and
.../configure --prefix=...
must build a native compiler that conforms to the native ABI of the
machine.
By my reading at least ppc, mips and sparc allow the default ABI to be changed
via --with-float, but none of them have a separate target triplet for this
purpose.
It's worth
Richard Earnshaw wrote:
The reason why a new triplet is required is that config.guess needs to
generate it when running native. Config.guess is the only way to
communicate the information needed for a native compiler when no other
information is communicated on the command line, and it only
On Mon, 2010-07-12 at 09:19 -0700, Mark Mitchell wrote:
Richard Earnshaw wrote:
The reason why a new triplet is required is that config.guess needs to
generate it when running native. Config.guess is the only way to
communicate the information needed for a native compiler when no other
It really does seem like a hack to use triplets in this way; I think
Paul's point that anything that depends on the toolchain triplet to
determine ABI is inherently busted is pretty persuasive.
Which means the whole GNU way of doing this has always been busted,
since that's essentially
Richard Earnshaw wrote:
Why not fix this? For example, it could also give back configure
options (--with-float=hard) that should be implicitly assumed to have
been provided.
That would be useful for GCC perhaps, but not for other projects that
use config.guess (which is part of the
19 matches
Mail list logo
