From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31892 invoked by alias); 31 Jul 2008 06:07:51 -0000 Received: (qmail 31880 invoked by uid 22791); 31 Jul 2008 06:07:49 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.177) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Jul 2008 06:07:19 +0000 Received: by py-out-1112.google.com with SMTP id w53so213100pyg.25 for ; Wed, 30 Jul 2008 23:07:17 -0700 (PDT) Received: by 10.65.97.18 with SMTP id z18mr16425249qbl.77.1217484437258; Wed, 30 Jul 2008 23:07:17 -0700 (PDT) Received: from ?192.168.0.101? ( [24.76.249.6]) by mx.google.com with ESMTPS id 25sm3354265qbw.1.2008.07.30.23.07.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Jul 2008 23:07:16 -0700 (PDT) Message-ID: <48915696.8090608@users.sourceforge.net> Date: Thu, 31 Jul 2008 06:07:00 -0000 From: "Yaakov (Cygwin Ports)" User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: cygwin-apps@cygwin.com Subject: Re: [RFC] 1.7 Packaging: Toolchain References: <48881261.3080504@users.sourceforge.net> <039301c8f17a$f36c14f0$9601a8c0@CAM.ARTIMI.COM> In-Reply-To: <039301c8f17a$f36c14f0$9601a8c0@CAM.ARTIMI.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00189.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dave Korn wrote: | 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. This thread seems to explain the logic behind libsupc++: http://gcc.gnu.org/ml/gcc/2001-06/msg01886.html I'd say it makes the most sense to stick with the upstream shared-libstdc-static-libsupc setup. I gather that this this isn't creating a complete libstdc++ though, but I don't see why. libsupc++ is being linked in via a convenience lib, which means that it should be linking the .a with -Wl,--whole-archive, and exporting any symbols therein. Which method is being used for symbol exports, and what exactly is missing? BTW, what about libg2c/libobjc/libgcj? | That's my plan. May I dare ask for a timeframe? | 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. I'm not sure I follow. Is -mno-cygwin part of the "vanilla" gcc now? Yaakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiRVpYACgkQpiWmPGlmQSMUDwCgjpDBQYmtpanPQXAjrSccBAJM fIoAoK8gul9UBxBM0kAxU0hW09NGTiwS =zdr0 -----END PGP SIGNATURE-----