This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: PING Jan Nieuwenhuizen re libguile17
- From: Brian Dessent <brian at dessent dot net>
- To: Jan Nieuwenhuizen <janneke-list at xs4all dot nl>
- Cc: Dave Korn <dave dot korn at artimi dot com>, cygwin-apps at cygwin dot com, 'hanwen' <hanwen at xs4all dot nl>
- Date: Fri, 21 Mar 2008 11:57:05 -0700
- Subject: Re: PING Jan Nieuwenhuizen re libguile17
- References: <008701c860e3$466e8530$2e08a8c0@CAM.ARTIMI.COM> <1201795510.29879.13.camel@peder.flower> <012101c86429$d1714fc0$2e08a8c0@CAM.ARTIMI.COM> <1202134179.2951.44.camel@peder.flower> <027801c8673d$da646e20$2e08a8c0@CAM.ARTIMI.COM> <1206112018.15385.9.camel@peder.flower>
- Reply-to: cygwin-apps at cygwin dot com
Jan Nieuwenhuizen wrote:
> I rebuilt gcc (4.1.1) with --enable-fully-dynamic-string*) and rebuilt
> guile
> (http://lilypond.org/cygwin/release/guile/libguile17/libguile17-1.8.2-3.tar.bz2)
> and today finally got round to testing it. It does not seem to help.
Note that the Cygwin gcc is not using --enable-fully-dynamic-string, it
is using the patch in PR24196 which is a compromise between the
pessimization of assuming fully dynamic strings and the optimization of
assuming one global instance of _S_empty_rep_storage.
Also, I'm confused on another issue: if libguile exposes a C++ ABI then
mixing 4.1 and 3.4 should be incompatible anyway, regardless of PR24196,
by the fact that there are so many g++ changes between those major
versions. However looking at the exports of the DLL I see no C++
symbols. But if libguile does not expose a C++ ABI then why does the
PR24196-patched gcc cause it to work again? Or is it that it uses C++
internally and that is where the std::string-across-DLL-boundaries
problem occurs?
Brian