Running the C++ library tests in the GCC testsuite

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Running the C++ library tests in the GCC testsuite

Steve Ellcey-9

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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Running the C++ library tests in the GCC testsuite

Joseph Myers
On Wed, 7 Nov 2018, Steve Ellcey wrote:

> 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'"

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.).

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Running the C++ library tests in the GCC testsuite

Steve Ellcey-9
On Wed, 2018-11-07 at 17:39 +0000, Joseph Myers wrote:

> External Email
>
> On Wed, 7 Nov 2018, Steve Ellcey wrote:
>
> >
> > 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'"
> 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?

Steve Ellcey
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Running the C++ library tests in the GCC testsuite

Joseph Myers
On Wed, 7 Nov 2018, Steve Ellcey wrote:

> 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?
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).

--
Joseph S. Myers
[hidden email]