This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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:

What do you guys think?

Please let me know if you need any additional details as how did I built
the compiler, as I've done it both ways, manually as well as using
crosstool-ng, trying to find any problem in the way I was doing it.


P.S. As the mailing list does not accept too long messges, I've removed
the crosstool-ng build log, which can be found in the crossgcc mailing
list message:

The configuration  information from the compiler is:
$ arm-eabi-gcc -v
Using built-in specs.
Target: arm-eabi
Configured with: /home/davidfc/src/gcc-4.8.1/configure
--prefix=/opt/cortex-r4f_xtools --with-gmp=/opt/cortex-r4f_xtools
--with-mpfr=/opt/cortex-r4f_xtools --with-mpc=/opt/cortex-r4f_xtools
--target=arm-eabi --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-arch=armv7-r --with-cpu=cortex-r4f --with-mode=thumb
--with-abi=aapcs --with-float-abi=hard --with-fpu=vfpv3-d16 -v
Thread model: single
gcc version 4.8.1 (GCC)

-------- Original Message --------
Subject: 	arm[eb]-eabi-gcc for cortex-r4[f] with newlib has problems
with multilib/libraries.
Date: 	Sat, 15 Jun 2013 01:05:38 +0100
From: 	David Fernandez <>
To: <>

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
Conflicting architecture profiles A/R
failed to merge target specific data of file
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?

David Fernandez

#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);

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]