Re: toolchain/38804

[James Chacon <jmc%netbsd.org@localhost>]

The following reply was made to PR toolchain/38804; it has been noted by GNATS.

From: James Chacon <jmc%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, mark%mcs.vuw.ac.nz@localhost, 
uwe%netbsd.org@localhost
Subject: Re: toolchain/38804
Date: Wed, 25 Jun 2008 19:33:53 -0700

 On Jun 25, 2008, at 6:30 PM, Valeriy E. Ushakov wrote:
 
 > The following reply was made to PR toolchain/38804; it has been  
 > noted by GNATS.
 >
 > From: "Valeriy E. Ushakov" <uwe%netbsd.org@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc:
 > Subject: Re: toolchain/38804
 > Date: Thu, 26 Jun 2008 05:25:26 +0400
 >
 > On Thu, Jun 26, 2008 at 05:07:49 +0400, Valeriy E. Ushakov wrote:
 >
 >> The problem is that, as -fdump-class-hierarchy tells me,
 >> std::basic_filebuf<char, std::char_traits<char> > has shrunk from
 >> 500 to 492 bytes, so all <fstream> stuff gets broken.
 >
 > And that's b/c it has a __c_lock _M_lock; and in current
 > pthread_mutex_t has different size... *sigh*
 >
 > Oh, and libstdc++ doesn't list libpthread as NEEDED.
 >
 > -uwe
 >
 
 Even if it did this isn't a libstdc++ issue then. Ugg...
 
 So, when the replacement pthread library went in I'm assuming  
 everything that depended on the old one was simply bumped in version?
 
 Here it still sounds like that's the solution then.
 
 James