+++ 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 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
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 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/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
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.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
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
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 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
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 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
Hi Marcin. Would you consider passing
--enable-poison-system-directories to the cross compiler configure?
This makes the '-Wpoison-system-directories' option available which
warns you if the cross compiler picks up a library or header file from
/usr instead of the cross-build environment.
I'm tal
13 matches
Mail list logo
