On 07/10/10 12:54, a...@arndb.de wrote:
On Thursday 07 October 2010 13:03:14 Wookey wrote:
gcc has the multilib feature, but the way it is implemented means it
works well for about 2 or 3 options, but you rapidly get combinatorial
explosion of libgcc instances if you try to do more things than t
Hi,
On Thu, Oct 7, 2010 at 3:13 PM, Wookey wrote:
[...]
> And whilst on the subject - do the other libs like gomp mudflap and
> erm that come of of toolchain builds need to be built in
> the same set of flavours or is this issue restricted to libgcc?
I think that libgcc is the only thing you ca
+++ Andrew Stubbs [2010-10-07 12:46 +0100]:
> On 07/10/10 12:03, Wookey wrote:
> A possible solution to the problem would be to include the sources to
> libgcc.a in the installation, and teach gcc to compile it on-the-fly, as
> necessary.
If it was possible to separate-out libgcc somewhat so
On Thursday 07 October 2010 13:03:14 Wookey wrote:
> gcc has the multilib feature, but the way it is implemented means it
> works well for about 2 or 3 options, but you rapidly get combinatorial
> explosion of libgcc instances if you try to do more things than that.
> (i.e if you ask for v5, v6, v7
On 07/10/10 12:03, Wookey wrote:
gcc has the multilib feature, but the way it is implemented means it
works well for about 2 or 3 options, but you rapidly get combinatorial
explosion of libgcc instances if you try to do more things than that.
(i.e if you ask for v5, v6, v7, vfp, and neon options
+++ John Rigby [2010-10-06 08:31 -0600]:
> I'm really sorry to have started this, but for completeness here is
> the rest of the story. The hypothetical scenario is a developer that
> maintains u-boot for multiple platforms. Using a codesourcery or eldk
> (from denx.de) toolchain one can use the
On Wed, Oct 06, 2010, John Rigby wrote:
> I'm really sorry to have started this, but for completeness here is
> the rest of the story.
No need to be sorry, I think you're doing right to bring this up
> The hypothetical scenario is a developer that
> maintains u-boot for m
I'm really sorry to have started this, but for completeness here is
the rest of the story. The hypothetical scenario is a developer that
maintains u-boot for multiple platforms. Using a codesourcery or eldk
(from denx.de) toolchain one can use the appropriate -march= to get
the right code from th
On Tue, Oct 05, 2010, Steve Langasek wrote:
> OOI, what are the U-Boot targets you're looking to build for that don't
> support ARMv7? A gcc multilib package for armel will be easy to implement
> but hard to maintain, and certainly none of the systems Linaro is targeting
> should require a pre-Thu
On Wednesday 06 October 2010, Steve Langasek wrote:
> It sounds like what you need for this is a multilib-enabled armel compiler
> build, that includes a libgcc build for ARMv7 as well as separate libgcc
> builds for whichever other ARM targets you're after. You should coordinate
> this with Marci
On Tue, Oct 05, 2010 at 04:23:01PM -0600, John Rigby wrote:
> Thanks Michael. Just wanted to make sure I understood. The "do no
> harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
> however. I realize that choices need to be made and only odd ducks
> like me will likely run into
On Wed, Oct 6, 2010 at 11:23 AM, John Rigby wrote:
> Thanks Michael. Just wanted to make sure I understood. The "do no
> harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
> however. I realize that choices need to be made and only odd ducks
> like me will likely run into issues.
Thanks Michael. Just wanted to make sure I understood. The "do no
harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
however. I realize that choices need to be made and only odd ducks
like me will likely run into issues. My particular case is wanting to
build u-boot for old and
On Wed, Oct 6, 2010 at 10:44 AM, John Rigby wrote:
> I believe that the libgcc.a in our toolchain contains Thumb-2 code. I
> verified this by doing objdump on libgcc.a and I see combinations of
> 16 and 32 bit instructions. So does that mean that the toolchain is
> only usable for ARM versions t
I believe that the libgcc.a in our toolchain contains Thumb-2 code. I
verified this by doing objdump on libgcc.a and I see combinations of
16 and 32 bit instructions. So does that mean that the toolchain is
only usable for ARM versions that support Thumb-2?
Thanks,
John
15 matches
Mail list logo