This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Regression checking vs. my -shared-libgcc patch
At 23:37 2001-02-04, Mark Mitchell wrote:
> >>>>> "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?
Well, I'm not really authorative for EABI issues, but as far I can parse
the stuff in rs6000/eabi*.asm, nothing of that needs to end up in
libgcc_s.so. So if that is true and we want to go with minimum changes, I
would suggest to change rs6000/t-ppccomm to something like:
LIB2FUNCS_EXTRA = tramp.S
LIB2FUNCS_NON_SHARED_EXTRA = eabi.S
and change gcc/Makefile.in to link
LIB2FUNCS_EXTRA+LIB2FUNCS_NON_SHARED_EXTRA into libgcc.a and to only link
LIB2FUNCS_EXTRA into libgcc_s.so. That would limit the impact to PPC for
now and all other targets can continue as normal. That should make the
regression tester happy again too.
But if this is a plausible solution probably only the EABI experts like
Geoff or Michael Meissner can tell.
> 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?
Hehe, it probably is appended, but I'm running under KDE2, so
LD_LIBRARY_PATH contains /usr/lib already :-/. I guess dejagnu should
actually prepend to LD_LIBRARY_PATH...
Franz.