Re: PATCH: Re: eh_globals.cc compilation errors with -threads under hpux 10.20

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> Under the assumption (based on Phil's comment that he punted ;-) that
> libstdc++/include/bits/c++config may now be further adjusted to
> address threading configuration issues, please know that I no longer
> wish you to refrain from installing parts of your patch on the
> mainline (with the further assumption that they will be moved to the
> 3.0 branch after we complete all other configuration changes needed to
> not break ports).  Additional commentary on parts of your patch now
> that I'm up to speed:

I have been working on this most of the day trying to adopt the configuration
technique used in libobjc.  I don't think it will be necessary to adjust
c++config.  I am to the point where things build and I believe that I
am now extracting the needed target configuration information from the
gcc source and build directories.

> - I still think you need to rework the part that adds THREADS_FLAGS
>   and sets it to -pthread since I think we have established that no
>   convention on that flag exists yet and (putting my release manager
>   hat on:) I don't think that Mark will look kindly towards a
>   mega-configuration patch which affects almost every port this close
>   to the 3.0 release.

I am currently testing and I think we do probably need THREADS_FLAGS to
get the proper linkage in the testuite for many ports.  I am wondering
if there is a better way to determine what is needed.  My patch
also doesn't set the flags for the deja harness.  So, I need to
figure out how to do that.

> - libstdc++-v3/config/threads-posix.h part is completely OK by me.
> 
> - Regarding the patch to libsupc++/eh_globals.cc, I don't know enough
>   yet (given that eh_threads_initialize seems to no longer exist, I
>   agree that a part of your patch is needed).  It seems that the root
>   problem is that when EH support for C++ was moved (or ar least a
>   portion was moved) from ../../gcc to a location under libstdc++-v3
>   "we" forgot to ensure that HAVE_GTHR_DEFAULT has to be defined, if
>   indeed it was configured that way in ../gcc, in order to properly
>   include gthr.h and thus get gthr_default.h and get __GTHREAD
>   properly defined, etc.
> 
> Regarding this last comment, I would like to make a patch to fix the
> root problem of misusing ../gcc/gthr.h.  I have known we were doing
> something funky for a while, but I wasn't hot on the problem until
> last week.  Since you have effectively done half the work David, would
> you like to be a co-author of the patch?  We can start by me sending
> you (and the list) a working draft.  My proposed patch to fix the root
> configuration problem will be the next transmission to you.
> 
> In article <200105231724.NAA20082@hiauly1.hia.nrc.ca>,
> "John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:
> 
> > I also have been doing a little digging trying to find out if _PTHREADS
> > is used by pthreads and have been unable to find any use of this symbol.
> > It seems that it was introduced within gcc to control the loading of
> > the correct thread file by gthr.h.

I think I now have resolved this problem.  We need to include "tconfig.h".

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)