This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Some remarks running the testsuite
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: Some remarks running the testsuite
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 03 Apr 2001 01:53:12 -0300
- Cc: Peter Schmid <schmid at snake dot iap dot physik dot tu-darmstadt dot de>, libstdc++ at gcc dot gnu dot org
- Organization: GCC Team, Red Hat
- References: <Pine.SOL.3.91.1010402161226.5389B-100000@cse.cygnus.com>
On Apr 2, 2001, Benjamin Kosnik <bkoz@redhat.com> wrote:
> Alexandre, I'm cc'ing you because libstdc++.so is not being generated
> correctly.
It is generated correctly. Nowhere does the testsuite tell programs
to search for libgcc_s.so in the build tree. And it wouldn't be
reasonable to have the libgcc build directory encoded in libstdc++,
because then it would be wrong for the installable libstdc++. If
libgcc_s were a libtool library, and libtool was used to link
executables with libstdc++, libtool would automatically take care of
linking libstdc++ in the build tree so that it would find libgcc_s in
the build tree, and of installing a differently-linked libstdc++ that
would look for libgcc_s in the install tree. But libgcc_s is not a
libtool library, and there's no directive telling libtool where to
look for libgcc_s at run-time, so there's nothing libtool can do about
it.
Having LD_LIBRARY_PATH set so that libgcc_s would be found in the
build *might* help, but I'm not sure it's guaranteed to help on all
systems. Shared libraries alone are already confusing; managing
inter-library dependencies just gets things worse :-(
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me