This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Cannot (cross-)build newlib 2.21 with GCC for arm-eabi target
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Emmanuel Blot <eblot dot ml at gmail dot com>
- Cc: "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Fri, 16 May 2014 09:18:11 +0100
- Subject: Re: Cannot (cross-)build newlib 2.21 with GCC for arm-eabi target
- Authentication-results: sourceware.org; auth=none
- References: <CAKJJEPwAGbTXS+r5-aFYA+Ux97xGAqQv9kYXWCzPx3RRyVSoKA at mail dot gmail dot com>
On 15/05/14 21:29, Emmanuel Blot wrote:
> Hi,
>
> I've been using newlib with GCC for many years (4.3 ... 4.9), but
> starting with the very latest official tarball (2.1), I can no longer
> build newlib along with GCC.
>
> There is no issue if I replace newlib 2.1 with 2.0 using the very same
> compiler source, and the same binutils package (2.24).
>
> newlib/ and libgloss/ directories are copied to the top directory of
> gcc source, and gcc is built out of source using the following
> configure options (I've removed the path specifiers for the local
> library reps (gmp, mpfr, etc.):
>
> ../configure --target=arm-eabi
> --disable-shared --with-gnu-as --with-gnu-ld
> --with-newlib --enable-softfloat --disable-bigendian
> --disable-fpu --disable-underscore --enable-multilibs
> --with-float=soft --enable-interwork --enable-lto
> --with-multilib --enable-plugins
> --with-abi=aapcs --enable-languages=cc++
> --with-gmp --with-mpfr --with-mpc --with-cloog
> --with-isl --with-libelf --enable-cloog-backend=isl
> --disable-debug --disable-__cxa_atexit
>
> Here is the error message:
>
> ==> make
> make[4]: *** No rule to make target
> `../../../../libgloss/arm/../config/default.mh', needed by `Makefile'.
> Stop.
> make[3]: *** [all] Error 2
> make[2]: *** [stmp-bsp] Error 2
> make[1]: *** [all-target-libgloss] Error 2
> make: *** [all] Error 2
>
>
> Any idea of what could go wrong? Maybe the way to build newlib has
> been changed since 2.0?
>
> Thanks,
> Manu.
>
This was a known problem that's been fixed on trunk. I believe it only
shows up if you use a relative path to invoke configure. You can work
around it by using a full path to the configure command.
R.