From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23527 invoked by alias); 29 Jul 2008 12:59:56 -0000 Received: (qmail 23504 invoked by uid 22791); 29 Jul 2008 12:59:55 -0000 X-Spam-Check-By: sourceware.org Received: from mail.artimi.com (HELO mail.artimi.com) (194.72.81.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jul 2008 12:59:37 +0000 Received: from ALBATROSS ([192.168.1.150]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jul 2008 13:59:35 +0100 From: "Dave Korn" To: References: <48881261.3080504@users.sourceforge.net> Subject: RE: [RFC] 1.7 Packaging: Toolchain Date: Tue, 29 Jul 2008 12:59:00 -0000 Message-ID: <039301c8f17a$f36c14f0$9601a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48881261.3080504@users.sourceforge.net> X-IsSubscribed: yes Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-07/txt/msg00167.txt.bz2 Yaakov (Cygwin Ports) wrote on 24 July 2008 06:26: > 2) gcc > > There are several issues to consider here: > > a) _GLIBCXX_USE_WCHAR_T > > Will std::wstring and friends be possible with cygwin-1.7? If not, is > there anything that can be done to make it possible? If the DLL supports it, then the autoconf tests should detect it and libstdc++ should build it and everything should "just work". > b) 3.4 vs. 4.3 > > I see little reason to work on gcc-4.3 for cygwin-1.5 at this point. Well, working on it for one is the same as working on it for the other anyway. > But this would be a great time to make the jump in release-2. Dave, I > know you're working on 4.3, so could you give us a status report? > Besides wstring, what is the story with shared gcc libraries (libgcc, > libstdc++, etc.)? I've got libgcc shared and working fine and correctly, either with a separate static libgcc_eh, or with it shared, although that's only an option if you also have shared libstdc++. Getting libstdc++ to work shared is being tricky; for some reason libsupc++ is only built static, which means libtool links it into libstdc++ only to resolve imports, not as objects that need to be exported. Removing the --disable-shared libtool tag from libsupc++'s build configuration gets me what appears to be a complete libstdc++, but it fails in early startup, probably down to the relocs-in-.rodata issue; and that's where I've got to. I'm not sure whether to just try and go for a shared-libstdc-static-libsupc combo, or to try and figure out what needs to be fixed to prevent the relocs problem - if indeed that's what it is. > If either of these changes to gcc will be available (particularly 4.3 > and/or shared libs), then we'll want that version of gcc available in > release-2 ASAP. That's my plan. > c) -mno-cygwin > > IMHO it's time for this insanity to end. Too many 3PPs abuse Cygwin as > if it were MSYS, and new users just seem to get confused by it. I > imagine it must make gcc that much harder to maintain as well. > > What we should do is treat mingw32 as any other cross-compiling target, > by providing i686-pc-mingw32-* binutils and gcc, and move > /usr/{include,lib}/mingw to /usr/i686-pc-mingw32/ (currently these are > symlinks). > > It may not be a pressing issue itself, but while we're making changes > anyway, isn't now the time? Famous last words. Yes, that's the scheme we decided on some time ago, but given how long it's already taking to get vanilla gcc4 working, I was just going to leave that as it stands for now. cheers, DaveK -- Can't think of a witty .sigline today....