X-Spam-Check-By: sourceware.org Message-ID: <445646ED.8090004@variadic.org> Date: Mon, 01 May 2006 10:35:41 -0700 From: Steven Brown User-Agent: Thunderbird 1.5.0.2 (X11/20060421) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Fixing the state of C++ in Cygwin References: In-Reply-To: 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-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 (resending as the list seems to have eaten it, apologies if it gets duplicated) Angelo Graziosi wrote: > It seems that applying the patch only, without rebuilding GCC works (the > ROOt, a CERN application, problems seem solved). The template is explicitly instantiated in libstdc++, so that shouldn't work afaik. The compiler won't be compiling the modified code, as it trusts it will find it already compiled during link. Does rOOt disable explicit instantiation via tweaking _GLIBCXX_EXTERN_TEMPLATE? At first, I tried writing m4 to apply the patch and disable the explicit instantiation as a transparent fix[1], but it only worked in some cases. From my understanding of that part of the toolchain, it gets in a non-deterministic linking state. There will be an implementation of the template compiled in libstdc++ and your code (if explicit instantiation is disabled). When it goes to link (remember, libstdc++ is linked statically in Cygwin), the linker is going to remove the duplicate, which might be the new one or the old one. [1] https://svn.variadic.org/public/trunk/ax_dll_string_fix/ax_dll_string_fix.m4 -- 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/