[Bug libstdc++/66530] New: libstdc++ testsuite links to incorrect shared libstdc++ library

[Bug libstdc++/66530] New: libstdc++ testsuite links to incorrect shared libstdc++ library

[jy38 at zips dot uakron.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

            Bug ID: 66530
           Summary: libstdc++ testsuite links to incorrect shared
                    libstdc++ library
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jy38 at zips dot uakron.edu
  Target Milestone: ---
              Host: x86_64-pc-cygwin
            Target: x86_64-pc-cygwin
             Build: x86_64-pc-cygwin

While running the testsuite for libstdc++, I noticed that the generated test
programs do not appear to be linking to the "correct" libstdc++ shared library
(that is, the libstdc++ that was generated in the build tree). As a result, the
testsuite generates erroneous test results even though I have modified various
files in the local source tree so that it should not.

Here's an excerpt from libstdc++.log containing the command-line used to
generate test program "hexfloat"
(27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc) and its subsequent
failure:

extra_tool_flags are:
 -std=gnu++11
Executing on host: /cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/./gcc/xg++
-shared-libgcc -B/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/./gcc -nostdinc++
-L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src
-L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src/.libs
-L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem
/usr/local/x86_64-pc-cygwin/include -isystem
/usr/local/x86_64-pc-cygwin/sys-include
-B/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR="." -nostdinc++
-I/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin
-I/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/include
-I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/libsupc++
-I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/include/backward
-I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/util
/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
  -std=gnu++11 ./libtestc++.a -Wl,--gc-sections -liconv
-L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src/filesystem/.libs
    -o ./hexfloat.exe    (timeout = 600)
spawn /cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/./gcc/xg++ -shared-libgcc
-B/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/./gcc -nostdinc++
-L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src
-L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src/.libs
-L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem
/usr/local/x86_64-pc-cygwin/include -isystem
/usr/local/x86_64-pc-cygwin/sys-include
-B/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-DLOCALEDIR="." -nostdinc++
-I/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin
-I/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/include
-I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/libsupc++
-I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/include/backward
-I/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/util
/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
-std=gnu++11 ./libtestc++.a -Wl,--gc-sections -liconv
-L/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/libstdc++-v3/src/filesystem/.libs
-o ./hexfloat.exe
PASS: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc (test for
excess errors)
Setting LD_LIBRARY_PATH to
:/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/gcc:/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs::/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/gcc:/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs
spawn [open ...]
assertion "os && std::stod(os.str()) == d" failed: file
"/cygdrive/c/Users/yaoj3/Code/gcc/trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc",
line 53, function: void test01()
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc execution test

I've confirmed that the problem persists even with a separate test program
outside of the testsuite (compiled and run with pretty much the same flags and
LD_LIBRARY_PATH seen above). More tellingly, compiling with an additional
-static-libstdc++ flag causes the problem to vanish entirely, with the test
program exhibiting the desired behavior.

My hypothesis (and please correct me if I'm wrong) is that the libstdc++ that
is being loaded at runtime is the preexisting (unaltered/unpatched) library in
the install tree, rather than the altered/patched library in the build tree. Of
course, I could presumably install the library in order to obtain the expected
test results... however, the behavior that I've described would appear to
violate the GNU Makefile conventions for the "check" target (as described by
the manual for GNU make, which reads: "Perform self-tests (if any). The user
must build the program before running the tests, but need not install the
program; you should write the self-tests so that they work when the program is
built but not installed").

FYI, the output of xg++ -v:

Using built-in specs.
COLLECT_GCC=./gcc/build/trunk/gcc/xg++
Target: x86_64-pc-cygwin
Configured with: ../../trunk/configure --docdir=/usr/local/share/doc/gcc
--htmldir=/usr/local/share/doc/gcc/html -C --build=x86_64-pc-cygwin
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic --enable-languages=c,c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--disable-libada --disable-libgcj --disable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id
Thread model: posix
gcc version 6.0.0 20150610 (experimental) (GCC)

[Bug libstdc++/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jennifer Yao from comment #0)
> My hypothesis (and please correct me if I'm wrong) is that the libstdc++
> that is being loaded at runtime is the preexisting (unaltered/unpatched)
> library in the install tree, rather than the altered/patched library in the
> build tree.

If that's true it must be a cygwin problem, as it doesn't happen for other
targets. All testing should be done against the build tree, and that's what
happens for me.

Does the
/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs
directory in the LD_LIBRAY_PATH contain the libstdc++.so.6 library?

[Bug libstdc++/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[jy38 at zips dot uakron.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

--- Comment #2 from Jennifer Yao <jy38 at zips dot uakron.edu> ---
(In reply to Jonathan Wakely from comment #1)
> Does the
> /cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/
> src/.libs directory in the LD_LIBRAY_PATH contain the libstdc++.so.6 library?

The requisite DLL and import library are both present (cygstdc++-6.dll and
libstdc++.dll.a, respectively).

(In reply to Jonathan Wakely from comment #1)
> (In reply to Jennifer Yao from comment #0)
> > My hypothesis (and please correct me if I'm wrong) is that the libstdc++
> > that is being loaded at runtime is the preexisting (unaltered/unpatched)
> > library in the install tree, rather than the altered/patched library in the
> > build tree.
> 
> If that's true it must be a cygwin problem, as it doesn't happen for other
> targets. All testing should be done against the build tree, and that's what
> happens for me.

Are you sure that the libstdc++ in the build tree is the one that's loaded at
runtime on your system? I only ask because I don't have a Linux system to test
on, and it would be relatively easy to overlook since much of libstdc++ is
header-only anyway.

[Bug libstdc++/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-16
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jennifer Yao from comment #2)
> Are you sure that the libstdc++ in the build tree is the one that's loaded
> at runtime on your system? I only ask because I don't have a Linux system to
> test on, and it would be relatively easy to overlook since much of libstdc++
> is header-only anyway.

Absolutely 100% sure. I test it several times a day without installing anything
and if changes I made to non-header code were not testable without installing
the library I would have noticed years ago. For the most recent example, I
testing this patch without installing the library:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00917.html

The problem seems to be that LD_LIBRARY_PATH is only used for dlopen() on
cygwin, not for finding dynamically-linked shared libraries.

[Bug libstdc++/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 35788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35788&action=edit
Set PATH for all testsuites not just for libstdc++

Since the problem isn't specific to libstdc++ we should fix it globally for all
target libs.

[Bug libstdc++/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davek at gcc dot gnu.org

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Dave, would you be able to properly test the patch in comment 5? It should make
Cygwin use the just-built target libs not the existing ones already installed
on the system.

You could verify it by intentionally introducing an abort into the libstdc++
sources e.g.

--- a/libstdc++-v3/src/c++98/locale_init.cc
+++ b/libstdc++-v3/src/c++98/locale_init.cc
@@ -247,6 +247,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   locale::locale() throw() : _M_impl(0)
   { 
+    __builtin_abort();
+
     _S_initialize();

     // Checked locking to optimize the common case where _S_global

then in $target/libstdc++-v3 run "make && make check" (without "make install")
which should produce thousands of FAILs!

[Bug testsuite/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[jy38 at zips dot uakron.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

--- Comment #7 from Jennifer Yao <jy38 at zips dot uakron.edu> ---
(In reply to Jonathan Wakely from comment #4)
> Does this patch fix it?
> 
> --- a/libstdc++-v3/testsuite/lib/libstdc++.exp
> +++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
> @@ -226,6 +226,11 @@ proc libstdc++_init { testfile } {
>         if [info exists env(LD_LIBRARY_PATH)] {
>           verbose -log "LD_LIBRARY_PATH = $env(LD_LIBRARY_PATH)"
>         }
> +
> +        # Cygwin uses PATH not LD_LIBRARY_PATH, see
> https://gcc.gnu.org/PR66530
> +        if { [ishost "*-*-cygwin*"] } {
> +          setenv PATH "$ld_library_path:$env(PATH)"
> +        }
>      } else {
>         set compiler [transform "g++"]
>      }

Just tested setting PATH with a separate test program on Cygwin, and it works.
^_____^

[Bug testsuite/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[jenny.hyphen.fa at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530

--- Comment #8 from Jennifer Yao <jenny.hyphen.fa at gmail dot com> ---
I know this is horribly belated, but I *just* got around to testing the patch
proper, and I'm afraid to say that it does not appear to work.

(My last comment verified that setting PATH instead of LD_LIBRARY_PATH worked
on Cygwin using a separate test program. I did not test the patch then.)