This is an attempt to fix the problem described here:

https://sourceware.org/ml/newlib/2016/msg01139.html
https://gcc.gnu.org/ml/gcc/2016-12/msg00010.html

There is no change if libtool is used.

Some run-time support libraries provided by GCC (e.g. libgomp) use
configure checks to detect certain features, e.g. availability of
thread-local storage.  The configure script generates a test program and
tries to compile and link it.  It should use target libraries and
startfiles of the build tree if available and not random ones from the
installation prefix for this procedure.  The search directories
specified by -B are a bit special, see for_each_path() in gcc.c of the
GCC sources.  First a search is performed on all search paths with the
multilib directory appended (if desired), then a second search is
performed on demand with the base directory only.  For each multilib
there is a "newlib" subdirectory.  This directory is specified by a -B
option for the support libraries.  In order to find the newlib artifacts
(ctr0.o, libc.a, libg.a and libm.a) they must be located in a proper
multilib subdirectory withing the build directory.

Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>

0 files changed, 0 insertions, 0 deletions