On Mon, Apr 26, 2021 at 11:50 AM Jonathan Wakely <jwak...@redhat.com> wrote:
>
> 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.
Most targets do not need libatomic. libatomic only is added to the
link libraries for a few, specific targets (hpux, ppc32, riscv,
sparc32). And the testcases work if an older version of libatomic is
installed in the search path. If I configure GCC with a prefix where
I have libatomic already installed, it works.
Thanks, David
