[PATCH, libstdc++ testsuite] Correct path to libatomic

[Jonathan Wakely]

On 26/04/21 09:17 -0400, David Edelsohn via Libstdc++ wrote:
>On Mon, Apr 26, 2021 at 7:19 AM Jonathan Wakely <jwakely@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

Right, I understand the problem in theory (though I still question
whether it's even theoretically a problem for multilib paths), but my
point is that I don't see a problem in practice. It works fine. So I'm
curious why it works for me and not for you.

I've never seen this cause a problem on any target, with any level of
parallelism.

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

All you've done is restate the description of the patch. I read it. I
understand it. Please re-read my email. I'm not asking what the patch
does, I'm trying to find out why you need the patch and I don't.

It turns out that on gcc119 -L wrong-path/libatomic -latomic is
causing the tests to link to /usr/lib/libatomic.a (and ignoring the -L
option). So that answers my question. I wasn't seeing it because some
other libatomic was being found when the -L path was wrong.