On 26/04/21 09:17 -0400, David Edelsohn via Libstdc++ wrote:
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
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.
