From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26399 invoked by alias); 28 May 2003 17:48:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 26178 invoked from network); 28 May 2003 17:48:11 -0000 Received: from unknown (HELO mclean.mail.mindspring.net) (207.69.200.57) by sources.redhat.com with SMTP; 28 May 2003 17:48:11 -0000 Received: from wamui02.slb.atl.earthlink.net ([192.168.167.40]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 19L51v-0001NM-00; Wed, 28 May 2003 13:48:03 -0400 Received: from [192.168.167.60] by EarthlinkWAM via HTTP; Wed May 28 13:48:02 EDT 2003 Message-ID: <4124107.1054144083179.JavaMail.nobody@wamui02.slb.atl.earthlink.net> Date: Wed, 28 May 2003 20:43:00 -0000 From: Josh Loeb To: Eric Botcazou , Josh Loeb Subject: Bootstrap failure on Sparc Solaris2.8 Cc: gcc@gcc.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg02343.txt.bz2 Yep, that's it. The versions here for types.h and pthread.h are 1.66 and 1.28 respectively. Unfortunately I don't have root privileges here but have put in a request to have it looked at. Thank you for helping with this. I can't help but wonder what else is "out" here though--do you know off hand if there's any reason NOT to have the systems administrators get the up-to-date header files, e.g., that the ones that are there might be correct for some reason for this system? Best, and thanks again, Josh -------Original Message------- From: Eric Botcazou Sent: 05/28/03 11:43 AM To: Josh Loeb Subject: Re: Re: Re: Bootstrap failure on Sparc Solaris2.8 > > > Here is the line from the pre-processed eh_alloc.ii file > > static __gthread_mutex_t emergency_mutex ={{0,0,0,0,0}, {{{0}}}, 0}; > > It looks like __gthread_mutex_t is typedef'd from pthread_mutex_t, which > on my system (in /usr/include/sys/types.h) is defined as follows (note the > first struct has four members, as compared to the five zeroes in the first > initializer above): > > typedef struct _pthread_mutex { /* = mutex_t in synch.h */ > struct { > uint16_t __pthread_mutex_flag1; > uint8_t __pthread_mutex_flag2; > uint8_t __pthread_mutex_ceiling; > uint32_t __pthread_mutex_type; > } __pthread_mutex_flags; > union { > struct { > uint8_t __pthread_mutex_pad[8]; > } __pthread_mutex_lock64; > upad64_t __pthread_mutex_owner64; > } __pthread_mutex_lock; > upad64_t __pthread_mutex_data; > } pthread_mutex_t; > > I don't know enough about how everything hangs together to know for sure > that's what being used, but it looks like a possible culprit. There is obviously a mismatch between /usr/include/pthread.h and /usr/include/sys/types.h on your system. My version of /usr/include/sys/types.h is #pragma ident "@(#)types.h 1.68 02/06/10 SMI and contains: typedef struct _pthread_mutex { /* = mutex_t in synch.h */ struct { uint16_t __pthread_mutex_flag1; uint8_t __pthread_mutex_flag2; uint8_t __pthread_mutex_ceiling; uint16_t __pthread_mutex_type; uint16_t __pthread_mutex_magic; } __pthread_mutex_flags; union { struct { uint8_t __pthread_mutex_pad[8]; } __pthread_mutex_lock64; struct { uint32_t __pthread_ownerpid; uint32_t __pthread_lockword; } __pthread_mutex_lock32; upad64_t __pthread_mutex_owner64; } __pthread_mutex_lock; upad64_t __pthread_mutex_data; } pthread_mutex_t; and my version of /usr/include/pthread.h is #pragma ident "@(#)pthread.h 1.29 01/07/07 SMI" and contains (the unfixed macro) #define PTHREAD_MUTEX_INITIALIZER {{0, 0, 0, 0, 0}, {{{0}}}, 0} What are your versions? > I'm wondering if I'm doing something wrong at config time or build time. > Note as well, it appears that this is happening during the 64-bit compile > of libstdc++. Maybe simply a Solaris 8 bug. -- Eric Botcazou >