Re: 3.0.2 PATCH: Fix libstdc++ testsuite for multilibbed targets

[Benjamin Kosnik <bkoz at redhat dot com>]

>   To fix this, one needs to invoke testsuite_flags from the appropriate
>   multilib subdir and point ld_library_path to the correct directory so
>   libstdc++.so is found at runtime.
> 
> * With this change, the resulting binaries won't run since now the multilib
>   libgcc_s isn't found: for -m64, gccpath is something like
> 
>   <path to builddir>/sparc-sun-solaris2.8/sparcv9
> 
>   so one needs another .. (i.e. ../../gcc instead of ../gcc) to reach the
>   gcc build directory.  Since I've found no way to properly account for
>   this difference (dejagnu's libgloss.exp (get_multilibs) has the correct
>   directory in its comp_base_dir variable, but doesn't export it), I've
>   adapted a solution found in libjava.exp to use lookfor_file to locate
>   libgcc_s.so: originally, I used lookfor_file $tool_root_dir
>   gcc/libgcc_s.so (like libjava.exp), but this doesn't account for
>   different values of SHLIB_EXT on different platforms.  Therefore I now
>   locate libgcc.a and assume that libgcc_s.$(SHLIB_EXT) can be found in the
>   same directory.

Sounds sane.


> With those changes, I could successfully run make check with default and
> non-default multilibs on sparc-sun-solaris2.8 and mips-sgi-irix6.5.
> 
> Ok for branch and mainline?

Yep. Thanks.

I might suggest staging the check-in: do mainline first, then wait and 
see if others can reproduce your results. (David Billinghurst in 
particular seems to run into this.)

Yay!

-benjamin