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
On Thu, 7 Oct 2010, Andrew Stubbs wrote:
> There's another issue here: using a Linux user-space compiler to build for
> bare-metal is a bad plan. libgcc is built assuming that system calls and
> exceptions etc. work as they do in Linux user-mode. The Linux kernel is built
> with a user-space compi
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 10/7/2010 7:03 AM, Dave Martin wrote:
> However, just from consistency arguments, I think that if we were to
> have problems build linaro U-Boot with the linaro toolchain that would
> be a bad thing
>From a practical perspective, that is likely true.
However, the fact that the Linux kernel an
Hi,
> There's another issue here: using a Linux user-space compiler to build for
> bare-metal is a bad plan. libgcc is built assuming that system calls and
> exceptions etc. work as they do in Linux user-mode. The Linux kernel is
> built with a user-space compiler for convenience, but a) the kerne
On 07/10/10 13:08, Matthias Klose wrote:
they must have renamed that recently from --enable-multilib ;)
Sneaky bunch, those GCC maintainers!
right, the multilib options are in t-arm-elf, not in t-linux-armeabi.
The old t-linux has the ones for hard/softfp commented out.
Right, Linux compile
On 07.10.2010 13:55, Andrew Stubbs wrote:
On 07/10/10 12:36, Matthias Klose wrote:
last time I checked this "multilibs" feature was implemented by building
the toolchain N times. By which magic is the correct library selected? I
didn't find anything in fsf trunk which supports this kind of multi
Matthias Klose wrote:
> last time I checked this "multilibs" feature was implemented by building
the
> toolchain N times. By which magic is the correct library selected? I
didn't
> find anything in fsf trunk which supports this kind of multilibs builds.
No, you don't need to build the toolchain m
On 07/10/10 12:36, Matthias Klose wrote:
last time I checked this "multilibs" feature was implemented by building
the toolchain N times. By which magic is the correct library selected? I
didn't find anything in fsf trunk which supports this kind of multilibs
builds.
It's there, and has been sin
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
On 07.10.2010 13:26, Andrew Stubbs wrote:
On 06/10/10 15:48, Loïc Minier wrote:
On Wed, Oct 06, 2010, John Rigby wrote:
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
On 06/10/10 15:48, Loïc Minier wrote:
On Wed, Oct 06, 2010, John Rigby wrote:
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 righ
+++ 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 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, 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 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
22 matches
Mail list logo
