Running the C++ library tests in the GCC testsuite

[Steve Ellcey]

I have a question about the C++ library testsuite. I built and installed
a complete toolchain with GCC, binutils, and glibc in a directory ($T) and
then I run the GCC testsuite with this command:

# cd to GCC object directory
make -j50 check RUNTESTFLAGS="--tool_opts '--sysroot=$T -Wl,--dynamic-linker=$T/lib/ld-linux-aarch64.so.1 -Wl,-rpath=$T/lib64 -Wl,-rpath=$T/usr/lib64'"

When I look at the gcc.log, g++.log, gfortran.log files I see the -Wl options
that I specified being used when the tests are compiled, but when I look at
the C++ library test log file
(aarch64-linux-gnu/libstdc++-v3/testsuite/libstdc++.log) I do not see
the --rpath or other flags getting used. Is this expected? I have a
few tests that fail because of this and die with:

./check_nan.exe: /lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by ./check_nan.exe)

If I rerun by hand and add the --rpath, etc. flags the test works but I
am not sure why the test harness did not add them itself.

Steve Ellcey
***@cavium.com

[Joseph Myers]

Post by Steve Ellcey
I have a question about the C++ library testsuite. I built and installed
a complete toolchain with GCC, binutils, and glibc in a directory ($T) and
# cd to GCC object directory
make -j50 check RUNTESTFLAGS="--tool_opts '--sysroot=$T -Wl,--dynamic-linker=$T/lib/ld-linux-aarch64.so.1 -Wl,-rpath=$T/lib64 -Wl,-rpath=$T/usr/lib64'"

I advise instead putting those options in your board file.

set_board_info ldflags "-Wl,whatever"

Note that you also need to make your board file set LOCPATH and GCONV_PATH
appropriately (pointing the $sysroot/usr/lib/locale and
$sysroot/usr/lib64/gconv respectively) for libstdc++ locale tests to work
correctly with such a non-default glibc. That would be code in your
<target>_load procedure in the board file (or in such a procedure in a
file it loads via load_generic_config, etc.).

[Steve Ellcey]

External Email

I have a question about the C++ library testsuite.  I built and
installed
a complete toolchain with GCC, binutils, and glibc in a directory ($T) and
# cd to GCC object directory
make -j50 check RUNTESTFLAGS="--tool_opts  '--sysroot=$T -Wl,
--dynamic-linker=$T/lib/ld-linux-aarch64.so.1 -Wl,-rpath=$T/lib64
-Wl,-rpath=$T/usr/lib64'"

I advise instead putting those options in your board file.
set_board_info ldflags "-Wl,whatever"
Note that you also need to make your board file set LOCPATH and GCONV_PATH
appropriately (pointing the $sysroot/usr/lib/locale and
$sysroot/usr/lib64/gconv respectively) for libstdc++ locale tests to work
correctly with such a non-default glibc.  That would be code in your
_load procedure in the board file (or in such a procedure in a
file it loads via load_generic_config, etc.).

I copied unix.exp to unix-sysroot.exp and added this to it:

if {[info exists env(DEJAGNU_UNIX_SYSROOT_FLAGS)]} {
    set_board_info ldflags "$env(DEJAGNU_UNIX_SYSROOT_FLAGS)"
}

I figured I would deal with LOCPATH and GCONV_PATH later.  When
I do a partial testrun, I don't get any failures but I do get some
new unresolved tests like this:

Download of ./20000108-1.exe to unix-sysroot failed.
UNRESOLVED: gcc.dg/20000108-1.c execution test

Have ever seen this error?

S

[Joseph Myers]

Post by Steve Ellcey
if {[info exists env(DEJAGNU_UNIX_SYSROOT_FLAGS)]} {
    set_board_info ldflags "$env(DEJAGNU_UNIX_SYSROOT_FLAGS)"
}
I figured I would deal with LOCPATH and GCONV_PATH later.  When
I do a partial testrun, I don't get any failures but I do get some
Download of ./20000108-1.exe to unix-sysroot failed.
UNRESOLVED: gcc.dg/20000108-1.c execution test
Have ever seen this error?

By using a different name from unix.exp (and you don't want to have your
own file called unix.exp - too much risk of confusion), you're probably
making DejaGnu think it's remote, and so try to copy files to a host
called unix-sysroot. You'll need to set isremote for the board to 0 to
avoid that, if it's not in fact remote (or set hostname if it is remote).