Re: Regression checking vs. my -shared-libgcc patch

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:

    Franz> It's most probably the shared libgcc thing. I worked around that on linux by 
    Franz> simply removing eabi.S from LIB2FUNCS_EXTRA, since it's not used on linux 
    Franz> unless some -m switch is passed.
    Franz> I wonder if we need a LIB2FUNCS_SHARED_EXTRA? It seems to me none of the 
    Franz> stuff in eabi.S belongs in a shared libgcc... 

That sounds plausible.

It sounds like we should disable shared libgcc on some of these
targets until we resolve this.  I'm not quite sure how to do that; it
looks like things are set up to always use a shared libgcc if
--enable-shared is in use.

Until we know how to resolve this problem, it sounds like we should
just use --disable-shared when building for these targets, or else
apply your patch.  What do you think is a better option?

I think maybe we should just check in your patch to get the regression
tested back on track; it sounds like it won't actually affect that
many people.  Then, we can make progress on this issue later.  Does
that make any sense?

    Franz> BTW, are the -B options honored while searching for libgcc_s? It seems to me 
    Franz> that the libstdc++-v3 testsuite used /usr/lib/libgcc_s.so.0 even though a 
    Franz> valid -B was passed.

I tried to make the testsuite set LD_LIBRARY_PATH correctly, and it
seemed to work for me, but I could have been mistaken.

That's what this change in g++.exp was supposed to do.

      append ld_library_path ":${rootme}"

Can you tell for sure whether that's taking effect or not?

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com