X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Message-ID: <48CA1F81.3070802@users.sourceforge.net> Date: Fri, 12 Sep 2008 02:51:29 -0500 From: "Yaakov (Cygwin Ports)" User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1 References: <48C8FE4D DOT 1090103 AT users DOT sourceforge DOT net> <013401c9140b$22b569c0$9601a8c0 AT CAM DOT ARTIMI DOT COM> In-Reply-To: <013401c9140b$22b569c0$9601a8c0@CAM.ARTIMI.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dave Korn wrote: > :) If so, I will submit upstream. Actually I think I can probably do it > all with the hooks and overrides, but I haven't got up-to-date with the > prep_gnu_info changes yet ... In that case, you know where to find me. :-) > That's all I get from a default build, I'm not sure if --disable-libjava is > the upstream default right now but knowing the somewhat sorry state of libjava > on cygwin I wouldn't be surprised. (I'll give it a go and if anything manages > to compile, I'll ship it.) Perhaps when you have the next release with a standard cygport, > Because I didn't use libtool to do it. I think Aaron's patch to build > libgcc shared from upstream does it properly, so I'll be adopting it if I can, > otherwise I'll just crudely bodge it in. Since the name of the libgcc dll is manually specified in gcc/config/i386/{cygwin.h,t-cygwin}, isn't it just a matter of changing those to cyggcc_s-1.dll? Or am I missing something? > Didn't look at fortran and objc. Presuming that F95 and ObjC/ObjC++ don't have the problem with overrides that C++ has, it should be as simple as adding the -no-undefined flag. > The problem with making shared libstdc - it can be done - is that it shows > regressions, because win32 doesn't currently fully support the semantics of > weak symbols like ELF does. Specifically, since a DLL has to be > fully-resolved when it is linked, any references to e.g. operators new/delete > get statically resolved as internal calls within the DLL, and then when you > attempt to define a custom operator new/delete override within your > executable, it doesn't get interposed between the already-resolved calls and > their destinations within the DLL. > > This would make the C++ compiler non-compliant, so as it all works OK with a > static library, I'm shipping it that way for now. > > I plan to work on improving weak symbol support in binutils to resolve this > problem in the long run; I think we can make it work with a little bit of > thunk stubbery[*]. I think I get the picture; helping to figure that out is beyond me. > ? dunno. That's a whole nother story, isn't it? I suppose so. Definitely not urgent, just curious. Yaakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkjKH4EACgkQpiWmPGlmQSMuugCeOFPWFs0INxU540XaPYFgnFt0 gEQAoPckVVyAYmNM+rCP30qzfrmUOvOt =xgq0 -----END PGP SIGNATURE----- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/