For example, for GCC/GCN target (AMD GPUs), target libraries are built
individually per supported hardware ISA ('-march=[...]'). Testing such a
toolchain via, for example:
$ make RUNTESTFLAGS='--target_board=[...]/-march=gfx90a' check[...]
... does work fine for all 'check-gcc-[...]' as well as GCC-provided target
libraries, 'check-target-[...]'. Just for 'check-target-newlib', for the
example above, not the '-march=gfx90a' newlib libraries are linked in, but
instead always the default ones, which results in link FAILure. This is cured
simply by skipping use of 'newlib/testsuite/lib/flags.exp', so that the
standard search paths as determined by GCC, DejaGnu are used for newlib, too.
Regression testing newlib in conjunction with libgloss and
--enable-multilib can result in incompatible multilib versions of
newlib and libgloss being used during link.
This manifests on ARM target when newlib regression is run using a
GCC configured using --with-multilib-list=aprofile
With this configuration many of the multilib variants built are
mutually incompatible.
The issue is that the newlib dejagnu foo iterates each multilib
variant and correctly chooses the appropriate newlib variant but
always chooses the root/base libgloss variant.
The implementation of newlib/testsuite/lib/flags.exp contains the
following fragment:
set target_build_path "$objdir/$multibuildtop.."
The effect of this fragment is to explicitly select the root version
of libgloss, irrespective of the current multilib.
Digging around in VC it appears that the original implementation of
multlib magic came into the tree back in 2002 with:
6e9d950a (Thomas Fitzsimmons 2002-05-01 17:06:25 +0000 39)
In this initial version of multilib support, newlib was multilib
capable, but libgloss was not multilib capable, hence the necessity to
explicitly select the root libgloss version.
Subsequently flags.exp was modified to support out of tree testing:
cec1d3b4 (Jeff Johnston 2005-07-05 00:11:50 +0000 25)
This change is orthogonal to this issue, its effect is to exit early
in none multilib configurations.
Subsequently libgloss gained --enable-multilib support, the relevant
change is:
https://sourceware.org/ml/newlib/2006/msg00440.html
commit 00a4b31ad0
Author: Jeff Johnston <jjohnstn@redhat.com>
Date: Wed May 10 20:51:41 2006 +0000
This change enabled multilib support throughout libgloss, but ommitted
to adjust the flag.exp behaviour which anchors the libgloss multilib
selection to the base version.
The attached patch adjusts flags.exp to select the current multilib
variant of libgloss.
2015-11-06 Marcus Shawcroft <marcus.shawcroft@arm.com>
* testsuite/lib/flags.exp (libgloss_link_flags): Drop multilibtop
from target_build_path.
* Makefile.am (site.exp): Set tmpdir.
* Makefile.in: Regenerated.
* testsuite/lib/checkoutput.exp (newlib_check_output): Put
executables in $tmpdir.
* testsuite/lib/flags.exp (libgloss_link_flags): Use the original
libgloss version if not running in the build directory.
* testsuite/lib/newlib.exp (newlib_init): Put testglue.o in
$tmpdir.
* testsuite/lib/passfail.exp (newlib_pass_fail): Put executables
in $tmpdir.