arm[eb]-eabi-gcc for cortex-r4[f] with newlib has problems with multilib/libraries.

arm[eb]-eabi-gcc for cortex-r4[f] with newlib has problems with multilib/libraries.

[David Fernandez]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

Hi there,

I've built an arm[eb]-eabi-gcc for --with-cpu=cortex-r4[f]
--with-mode=thumb --with-newlib, both manually and with crosstool-ng. In
all cases, I get a strange problem when building a main function with
ful C runtime library support like this (include the latest version, but
it happens with the little endian, and with the cortex-r4 too):

$ armeb-eabi-gcc -mbig-endian -mthumb -march=armv7-r -mcpu=cortex-r4f -o
alignpack alignpack.c
/opt/x-tools/armeb-unknown-eabi/lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/bin/ld:
error:
/opt/x-tools/armeb-unknown-eabi/lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/lib/libc.a(lib_a-strlen-armv7.o):
Conflicting architecture profiles A/R
/opt/x-tools/armeb-unknown-eabi/lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/bin/ld:
failed to merge target specific data of file
/opt/x-tools/armeb-unknown-eabi/lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/lib/libc.a(lib_a-strlen-armv7.o)
collect2: error: ld returned 1 exit status

I'm pretty sure that when I built this same kind of compiler for a
cortex-m3, it did not do this.

Anyway, find attached the alignpack.c, and the crosstool-ng log. I had
to use newlib-2.0.0 to make it work with the tuple armeb-xxx.

I've tried additional multilib permutations, but the errors keep appearing.

Any thoughts?

Regards.
David Fernandez


[-- Attachment #2: alignpack.c --]
[-- Type: text/x-csrc, Size: 547 bytes --]


#include <stddef.h>
#include <stdint.h>

#define ALIGNEDP(x) __attribute__((aligned(x),packed))
#define ALIGNED(x) __attribute__((aligned(x)))


struct  s1 {
            uint32_t    a;
            uint16_t    b;
            uint32_t    c;
            char        d ALIGNED(16/__CHAR_BIT__);
            char        e ALIGNED(16/__CHAR_BIT__);
        } ALIGNEDP(16/__CHAR_BIT__);

typedef struct s1   s1_t;

void    main(void)
{
    volatile    int i,j,k;

    i = sizeof(s1_t);
    j = offsetof(struct s1,d);
    k = offsetof(struct s1,e);
}




[-- Attachment #3: build.tar.bz2 --]
[-- Type: application/x-bzip, Size: 385276 bytes --]

[-- Attachment #4: Type: text/plain, Size: 71 bytes --]

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: arm[eb]-eabi-gcc for cortex-r4[f] with newlib has problems with multilib/libraries.

[David Fernandez]

On 15/06/13 01:05, David Fernandez wrote:
> Hi there,
>
> I've built an arm[eb]-eabi-gcc for --with-cpu=cortex-r4[f]
> --with-mode=thumb --with-newlib, both manually and with crosstool-ng. In
> all cases, I get a strange problem when building a main function with
> ful C runtime library support like this (include the latest version, but
> it happens with the little endian, and with the cortex-r4 too):
>
> $ armeb-eabi-gcc -mbig-endian -mthumb -march=armv7-r -mcpu=cortex-r4f -o
> alignpack alignpack.c
> /opt/x-tools/armeb-unknown-eabi/lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/bin/ld:
> error:
> /opt/x-tools/armeb-unknown-eabi/lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/lib/libc.a(lib_a-strlen-armv7.o):
> Conflicting architecture profiles A/R
> /opt/x-tools/armeb-unknown-eabi/lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/bin/ld:
> failed to merge target specific data of file
> /opt/x-tools/armeb-unknown-eabi/lib/gcc/armeb-unknown-eabi/4.7.2/../../../../armeb-unknown-eabi/lib/libc.a(lib_a-strlen-armv7.o)
> collect2: error: ld returned 1 exit status
>
> I'm pretty sure that when I built this same kind of compiler for a
> cortex-m3, it did not do this.
>
> Anyway, find attached the alignpack.c, and the crosstool-ng log. I had
> to use newlib-2.0.0 to make it work with the tuple armeb-xxx.
>
> I've tried additional multilib permutations, but the errors keep appearing.
>
> Any thoughts?
>
> Regards.
> David Fernandez
>
Hi there,

After two weeks, the solution to this problem pop out to me. It was a
problem in the newlib strlen implementation, that was forcing the
armv7-a architecture.

This was solved some time ago in the cvs sources for newlib.

Regards.
David F.

--
For unsubscribe information see http://sourceware.org/lists.html#faq