This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Fixing the state of C++ in Cygwin
- From: Steven Brown <swbrown at variadic dot org>
- To: cygwin at cygwin dot com
- Date: Mon, 01 May 2006 10:35:41 -0700
- Subject: Re: Fixing the state of C++ in Cygwin
- References: <Pine.OSF.4.21.0604301216110.9489-100000@ax0rm1.roma1.infn.it>
(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/