This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: arm[eb]-eabi-gcc for cortex-r4[f] with newlib has problems with multilib/libraries.
- From: Will Newton <will dot newton at linaro dot org>
- To: David Fernandez <david dot fernandez dot work at googlemail dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Fri, 5 Jul 2013 10:01:39 +0100
- Subject: Re: arm[eb]-eabi-gcc for cortex-r4[f] with newlib has problems with multilib/libraries.
- References: <51BBAFD2 dot 3040300 at googlemail dot com> <51D5E84B dot 1060403 at googlemail dot com>
On 4 July 2013 22:25, David Fernandez
<david.fernandez.work@googlemail.com> wrote:
> Hi there,
>
> Given my problem in the e-mail below, which nobody in crossgcc seems to
> get any idea about it so far, I was wondering if it could have something
> to do with newlib itself. The problem looks like the newlib strlen gets
> compiled for the armv7-a architecture, regardless of specifying both the
> cortex-r4[f] cpu, and the armv7-r architecture as defaults when building
> the arm-eabi-gcc.
>
> There is a proposed patch for newlib that made me suspect that the
> armv7-a might be hard-coded somehow in the strlen implementation:
> http://sourceware.org/ml/newlib/2013/msg00474.html
Hi David,
Have you tried a build with that patch applied i.e. current newlib HEAD?
It looks like the old code explicitly set the architecture, whereas
the new code doesn't. Alternatively you could try deleting the line in
newlib/libc/machine/arm/strlen-armv7.S:
.arch armv7-a
--
Will Newton
Toolchain Working Group, Linaro