[Bug libgcj/28546] [4.2 Regression] ./java/lang/Thread.h:31: error: using typedef-name '_Jv_Thread_t' after 'class'

["toa at pop dot agri dot ch" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #3 from toa at pop dot agri dot ch  2006-07-30 21:06 -------
Subject: Re:  [4.2 Regression] ./java/lang/Thread.h:31:
 error: using typedef-name '_Jv_Thread_t' after 'class'

dave at hiauly1 dot hia dot nrc dot ca wrote:
> ------- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2006-07-30 20:51 -------
> Subject: Re:  [4.2 Regression] ./java/lang/Thread.h:31: error: using
> typedef-name '_Jv_Thread_t' after 'class'
> 
>> This is in include/no-threads.h.
> 
> Ah, that's correct since I see I specified '--enable-threads=single'.
> I was going to work further on the _REENTRANT problem but lost track
> of this fact.
> 
> In any event, we didn't used to hit this problem.  The forward
> declaration in Makefile.am seems like a hack.
> 
>> So, we either have a posix-thread detection issue on hppa2.0w-hp-hpux11.00 or
>> posix threads are not supported here.
>>
>> Just for the record, hppa2.0w-hp-hpux11.11 does work.
> 
> Probably not if configured with '--enable-threads=single'.  This is
> the default on hpux11.  POSIX threads are always available, so possibly
> we should just force posix threads.  On the otherhand, I'm still
> thinking that I would like '--enable-threads=single' to work for hpux10.

Right and right, and I think it is platform independent. If one uses 
--enable-threads=single on any platform we will hit this compilation 
problem.

So, the right way to solve this is to attack the include/no-threads.h place.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28546