On Mon, Apr 26, 2021 at 7:19 AM Jonathan Wakely <jwak...@redhat.com> wrote:
>
> On 23/04/21 20:54 -0400, David Edelsohn via Libstdc++ wrote:
> >Some ports require libatomic for atomic operations, at least for some
> >data types and widths. The libstdc++ testsuite previously was updated
> >to link against libatomic, but the search path was hard-coded to
> >something that is not always correct, and the shared library search
> >path was not set.
>
> In libstdc++_init we have:
>
> # Locate libatomic.
> set v3-libatomic 0
> set libatomicdir [lookfor_file $blddir/../libatomic
> .libs/libatomic.$shlib_ext]
> if {$libatomicdir != ""} {
> set v3-libatomic 1
> set libatomicdir [file dirname $libatomicdir]
> append ld_library_path_tmp ":${libatomicdir}"
> verbose -log "libatomic support detected"
> }
> v3track libatomicdir 3
>
> Which should have added it to the search path unconditionally, so that
> it will be found if a test is linked with -latomic and needs it. I
> Don't know why that's not working for AIX, I see it doing the right
> thing in the logs for x86_64-linux (and the path is right for the
> alternative unix/-m32 multilib tests):
>
> libatomic support detected
> libgomp support detected
> shared library support detected
> LD_LIBRARY_PATH=:/home/jwakely/src/gcc/build/gcc:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libatomic/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libgomp/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs:/home/jwakely/src/gcc/build/gcc/32
> LD_RUN_PATH=:/home/jwakely/src/gcc/build/gcc:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libatomic/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libgomp/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs:/home/jwakely/src/gcc/build/gcc/32
> SHLIB_PATH=:/home/jwakely/src/gcc/build/gcc:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libatomic/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libgomp/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs:/home/jwakely/src/gcc/build/gcc/32
> LD_LIBRARY_PATH_32=:/home/jwakely/src/gcc/build/gcc:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libatomic/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libgomp/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs:/home/jwakely/src/gcc/build/gcc/32
> LD_LIBRARY_PATH_64=:/home/jwakely/src/gcc/build/gcc:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libatomic/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libgomp/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs:/home/jwakely/src/gcc/build/gcc/32
> DYLD_LIBRARY_PATH=:/home/jwakely/src/gcc/build/gcc:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libatomic/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libgomp/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs:/home/jwakely/src/gcc/build/gcc/32
> LD_LIBRARY_PATH =
> :/home/jwakely/src/gcc/build/gcc:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libatomic/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/../libgomp/.libs:/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs:/home/jwakely/src/gcc/build/gcc/32
>
> >The search path was hard-coded to the expected location of the
> >libatomic build directory relative to the libstdc++ testsuite
> >directory, but if one uses parallelism when invoking the libstdc++
> >testsuite, the tests are run in the "normalXX" sub-directories, for
> >which the hard-coded search path is incorrect.
>
> This has occurred to me previously, and I checked it, and it works
> fine for parallel test runs. I must be running the tests differently
> from you, as I can't reproruce the problem.
>
> For example, in r11-8285 I added the libatomic options to
> 30_threads/semaphore/try_acquire_posix.cc because it was failing on
> AIX (on gcc119 specifically). With the { dg-add-options libatomic } in
> place it no longer fails. That is true for parallel and non-parallel
> test runs, and whether I run "make check" in the $target/libstdc++-v3
> directory, or $target/libstdc++-v3/testsuite, or run make
> check-target-libstdc++-v3 in the top-level build dir.
>
> >The path also is
> >incorrect for alternative multilib and tool options.
>
> Is it? For alternative multilibs we have something like:
>
> ./libstdc++/testsuite
> ./libatomic/.libs
> ppc64/libstdc++-v3/testsuite
> ppc64/libatomic/.libs
> pthread/libstdc++-v3/testsuite
> pthread/libatomic/.libs
>
> In each case, the relative path from the v3/testsuite directory to
> libatomic.a ia the same, ../../libatomic/.src
>
> The patch seems like an improvement, but I don't see the problem it
> was fixing.
The testsuite directory in the build tree would be
./libstdc++-v3/testsuite
and the original libatomic search path support unilaterally would add
../../libatomic/.libs
to the link path.
But if one runs the testsuite with parallelism, the testsuite adds an
additional level of subdirectories, e.g.,
./libstdc++-v3/testsuite/normal1
./libstdc++-v3/testsuite/normal2
./libstdc++-v3/testsuite/normal3
in which case ../../libatomic is not the correct path and "../.."
doesn't point into the root of the target libraries directory.
Depending on whether the testsuite is invoked with or without
parallelism, one needs an additional ".." in the libatomic path. The
patch uses the same logic as other parts of the testsuite to determine
the path relative to the gcc build directory, including the
TOOL_OPTIONS.
Thanks, David
