libstdc++/2841: -static in libstdc++ v3 dejagnu testsuite causes linking to fail

[Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>]

>Number:         2841
>Category:       libstdc++
>Synopsis:       -static in libstdc++ v3 dejagnu testsuite causes linking to fail
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May 16 03:56:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Rainer Orth
>Release:        3.0 20010514 (prerelease)
>Organization:
Faculty of Technology, Bielefeld University
>Environment:
System: OSF1 bartok V5.1 732 alpha
Machine: alpha
	
host: alpha-dec-osf5.1
build: alpha-dec-osf5.1
target: alpha-dec-osf5.1
configured with: /vol/gnu/src/gcc/gcc-3.0-branch/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --enable-shared --disable-nls alpha-dec-osf5.1
>Description:
The new dejagnu based testsuite enforces the -static switch when linking the
libstdc++ v3 testsuite.  This causes all links to fail (currently on Tru64 UNIX
V5.1, but there are other scenarios, see below):

FAIL: 17_intro/header_cassert.cc (test for excess errors)
WARNING: 17_intro/header_cassert.cc compilation failed to produce executable

In libstdc++-v3.log, I find

spawn /amnt/figaro/volumes/obj-gcc/gcc/obj.alpha/gcc-3.0-20010514/5.1-adu-cc/gcc/g++ -B/amnt/figaro/volumes/obj-gcc/gcc/obj.alpha/gcc-3.0-20010514/5.1-adu-cc/gcc/ -nostdinc++ -L/amnt/figaro/volumes/obj-gcc/gcc/obj.alpha/gcc-3.0-20010514/5.1-adu-cc/alpha-dec-osf5.1/libstdc++-v3/src -L/amnt/figaro/volumes/obj-gcc/gcc/obj.alpha/gcc-3.0-20010514/5.1-adu-cc/alpha-dec-osf5.1/libstdc++-v3/src/.libs -B/vol/gcc/share/alpha-dec-osf5.1/bin/ -B/vol/gcc/share/alpha-dec-osf5.1/lib/ -isystem /vol/gcc/share/alpha-dec-osf5.1/include -ggdb3 -DDEBUG_ASSERT -nostdinc++ -I/amnt/figaro/volumes/obj-gcc/gcc/obj.alpha/gcc-3.0-20010514/5.1-adu-cc/alpha-dec-osf5.1/libstdc++-v3/include -I/vol/gnu/src/gcc/gcc-3.0-branch/libstdc++-v3/include -I/vol/gnu/src/gcc/gcc-3.0-branch/libstdc++-v3/include/std -I/vol/gnu/src/gcc/gcc-3.0-branch/libstdc++-v3/include/c_std -I/vol/gnu/src/gcc/gcc-3.0-branch/libstdc++-v3/libsupc++ -I/vol/gnu/src/gcc/gcc-3.0-branch/libstdc++-v3/libio -I/vol/gnu/src/gcc/gcc-3.0-branch/libst!
!
dc++-v3/testsuite -I/vol/gnu/src/gcc/gcc-3.0-branch/libstdc++-v3/include/backwards -I/vol/gnu/src/gcc/gcc-3.0-branch/libstdc++-v3/include/ext -static /amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.0-branch/libstdc++-v3/testsuite/17_intro/header_cassert.cc -DDEBUG_ASSERT -lm -o ./a.out
/usr/bin/ld:
Can't locate file for: -lm
collect2: ld returned 1 exit status
compiler exited with status 1

I could trace this down to the fact that -static is passed to all link commands
and the machine in question didn't have a static libm installed.

This is an incompatible change from the old mkcheck-based testsuite, and wrong
for a couple of reasons:

* The old testsuite used libtool to link, while the new dejagnu-based one uses
  g++ directly.  While the old static tests used -static as well, this was the
  libtool flag, which means `prefer a static library if there is a choice',
  while gcc's -static flag means `enforce static linking, fail if a static
  library cannot be found'.  This is equivalent to libtool's -all-static flag,
  which was not used for good reason.

* Namely, this doesn't test what a user of the installed g++/libstdc++ would
  use: they would call g++ -static only in exceptional circumstances, since
  this would create enormous binaries by default.  Instead, the testsuite should
  test the version of libstdc++ which has been build during the configure run, 
  thus respecting either the default or any --enable-shared or --disable-shared
  switches the user has specified when configuring the compiler.

* Static libraries may not be available, so all tests spuriously fail.  This 
  may be due to an installers choice (like in the present Tru64 UNIX case), or
  by OS design (like on 64-bit Solaris 8, where there are no static versions
  of system libraries at all).
>How-To-Repeat:
make check on systems that lack static libraries
>Fix:
I think there are two thinks necessary to get this working properly:

* the -static flag needs to be removed.  I have hacked libstdc++-v3-dg.exp to
  do this, and immediately discovered why it may have been added in the first
  place: without it, the shared libgcc_s isn't found, since LD_LIBRARY_PATH
  (or it's ld_library_path dejagnu equivalent) isn't set to include the build
  directory where it is found.

  I've hacked the Makefile to set ${rootme} (the gcc build directory) in
  site.exp, and added ${rootme} to ld_library_path.  With this change, I get
  this testsuite result on Tru64 UNIX V5.1 (with my yet unreviewed initial port
  to that platform, http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00281.html):

                === libstdc++-v3 Summary ===

# of expected passes            207
# of unexpected failures        13
# of unexpected successes       6
# of expected failures          8

  which looks quite reasonable for a first attempt :-)

  Unfortunately, this isn't sufficient: while on Tru64 UNIX V5.1 (despite passing
  --enable-shared to the gcc configure) only a static libstdc++.a is build
  and this there's no problem finding that at runtime, on Solaris 8/SPARC
  libstdc++.so.3 is built as well, and without -static, ld_library_path needs
  to be augmented to find it as well.  Some logic to do so is in the libjava
  and libobjc testsuites.

* Unfortunately, this all requires detailed internal knowledge of libtool, so
  instead libtool should be used both to compile/link (as in mkcheck) and run
  (not done before) the testsuite programs, and a common dejagnu framework
  established for doing so, instead of hacking every language/libraries .exp
  files to contain the necessary magic.

  For the last part (using libtool to run the programs), there's probably one
  obstacle: while currently all libraries are built with libtool and so the
  necessary .la files are in place, libgcc_s is not, so libtool wouldn't know
  how to find it, again requiring special hair to deal with this.

  I don't understand the rational for this special treatment of libgcc_s (which
  will probably the subject of another message/report).
>Release-Note:
>Audit-Trail:
>Unformatted: