General multilib of libgcc issue (was: ``Re: Threads vs hpux10'')

[Loren James Rittle]

You wrote:

>> Yea, please do send it.  I'm more than open to better solutions :-)

I wrote:

> Perhaps you could explain why gthr-dce.h is being used at all to build
> the multilib for single-threaded use on your platform.  I thought that
> the whole point of the THREAD_MODEL_SPEC setting as shown above was to
> get the right gthr-X.h file in light of multilibing.  There might be a
> more general problem that we need to fix (I sure hope not).

Hi (again) Jeff,

OK, I figured it out.  The above is true for libstdc++-v3 and other
recent language libraries when it is multilib'd but it is not true for
libgcc itself.  While looking at alphaev67-dec-osf5.1 (configuration
of --enable-threads=posix) for the first time since gcc 2.95.1 on
alpha-dec-osf4.0f, I see the same problem you encountered on HPUX10
(however, it doesn't produce a fatal bootstrap error on OSF).

The root problem is that gthr-default.h is created only once in
$objdir/gcc instead of once per multilib configuration.  (In case
anyone cares, alphaev67-dec-osf5.1 is not currently multilib'd but it
looks like it should be when --enable-threads=posix is configured if
and only if weak symbol support can't be made to work like it does on
other platforms - frankly, other than a vague memory of an e-mail
thread on the topic of differences in weak symbol support, I don't
know if weak symbol support is currently broken on this platform or if
it is suppose to work differently but I do know it doesn't work like
it does on Linux, FreeBSD and Solaris [1])...

Anyways, you wanted to know the better solution.  If libgcc were built
like every other multilib'd language library then gthr-default.h
should be created in $objdir/gcc/<multilib-directory>/libgcc once per
multilib configuration instead of once in $objdir/gcc .  Then,
$objdir/gcc/<multilib-directory>/libgcc should be added to the header
search path while building libgcc.  This solution will handle all
platforms with the problem once they have been updated with the
correct THREAD_MODEL_SPEC setting and multilib'd as appropriate (as
you know but other readers may not, platforms that support weak
symbols ala ELF usually use the weak symbol trick to avoid
multilib'ing thread support).

Looking at gcc/configure.in and how gthr-default.h is currently
created before we even have an xgcc to report thread configuration
(compare and contrast to how it is done in libstdc++-v3, boehm-gc,
libjava), I suppose that your patch was as good as any until/if libgcc
multilib support is updated to support the use of different headers in
light of multilib options.  Sorry to have raised a red herring with
your patch but I did learn how to multilib a configuration while
investigating this issue so it wasn't a total waste IMHO.

Regards,
Loren

[1] Should this program be linkable without error or warning on all
    platforms that properly support weak symbols?

    extern void f() __attribute__ ((weak));

    int main(){ if (f) f(); return 0; }

    It seems that OSF1 means something quite a bit different by weak
    than e.g. Solaris, FreeBSD or Linux...  It seems wrong to me for a
    feature exposed to the user to act so differently when mapped to
    different platform's native concept of weak...