Dave Korn writes:
Hi Dave,
It looks to me as if cygguile-17.dll needs to be rebuilt with an up-to-date
gcc with the fix for throwing strings across dll boundaries. As we discovered
in a recent thread[*], autogen crashes on exit[**], and it appears to be due
to a problem in libguile[***].
Dave Korn:
Is this meant to be as offensively patronising as it came out?
Sorry, I should have added at least a smiley. Having said that, I've
torn quite some hair over trying to unpack gcc's source packages. They
seem unnecessary difficult to unpack automatically, and as you asked why
one
Jan Nieuwenhuizen wrote on 27 March 2008 11:10:
Dave Korn:
Is this meant to be as offensively patronising as it came out?
Sorry, I should have added at least a smiley. Having said that, I've
torn quite some hair over trying to unpack gcc's source
packages. They
seem unnecessary
Dave Korn writes:
What exactly is the nature of the problem? It all seems fairly
straightforward to me, but that's not to say it can't be changed if there's
a reason to.
As I remember the problematic thing is that there are so many options
for this second variant of Cygwin's source
Dave Korn writes:
The C ABI is meant to be the same between 3.x and 4.x, so since there's
apparently no C++ involved, I don't think this is necessarily simply an ABI
incompatibility, I think it's a real regression.
I tested compiling libguile for Cygwin using gcc-4.0.0, gcc-4.0.4, and
Jan Nieuwenhuizen wrote on 26 March 2008 11:22:
I *am* willing to do maintenance releases of the 3.4 compiler
if there are important bugs to fix, doubly so if it's needed to support
a package in the official distro.
What is the best gcc 3.4 to use for Cygwin?
/usr/bin/gcc, i.e.
Dave Korn writes:
/usr/bin/gcc, i.e. the latest release in the distro.
Ah, I meant source-wise, I do not run Cygwin.
Unpacking Cygwin's gcc/g++
source archive in a python script is a bit of a pain (that's an
understatement :-).
I don't understand why that would be necessary?
Jan Nieuwenhuizen wrote on 26 March 2008 15:20:
Dave Korn writes:
/usr/bin/gcc, i.e. the latest release in the distro.
Ah, I meant source-wise, I do not run Cygwin.
It comes in a source distribution as well, same as all cygwin packages.
Unpacking Cygwin's gcc/g++
source
Jan Nieuwenhuizen wrote on 25 March 2008 09:50:
Brian Dessent:
I rebuilt libguile with gcc 3.4.4-1 (without any PR24196 patches) and an
autogen using it passes all tests. So it seems this is simply an ABI
incompatibility between 4.1 and 3.4.
Thanks. I'll start a test using
Brian Dessent:
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.
Hmm, so I
Jan Nieuwenhuizen wrote on 22 March 2008 13:03:
Brian Dessent:
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
Jan Nieuwenhuizen wrote:
libguile does not use C++. As far as I understand, it is a problem that
is introduced while linking the dlls.
The problem addressed by PR24196 and --enable-fully-dynamic-string is
entirely centered around an implementation detail of std::string in
libstdc++.
Brian Dessent wrote on 22 March 2008 16:50:
However, I have in fact verified myself that rebuilding libguile with
Cygwin gcc 3.4.4 with the PR24196 patch does fix the problem.
Thanks for the confirmation.
I'm now
wonderding if PR24196 is a red herring and the real issue is an ABI
Dave Korn wrote:
I don't think I actually tried this at the time, I used a self-built
libguile vs. the shipped distro version. It'll be interesting to see your
results.
I rebuilt libguile with gcc 3.4.4-1 (without any PR24196 patches) and an
autogen using it passes all tests. So it seems
Dave Korn:
Hi Dave,
LilyPond does not support gcc 3.x anymore, would it be of any use to
try rebuilding guile with the --enable-fully-dynamic string option?
You need to build the /compiler/ using that option, not the target
application, but apart from that yes: it should then fix your
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
On 04 February 2008 14:10, Jan Nieuwenhuizen wrote:
http://gcc.gnu.org/PR24196
I see...
The fix is almost - but not quite - equivalent to applying the
--enable-fully-dynamic-string configure option, but hopefully has the
advantage of being ABI-compatible.
As a bit of generic advice
Dave Korn writes:
Hi Dave,
There is a cygwin-local fix in 3.4.4-3 that is essential for correctness
when throwing exceptions or passing std::string objects across DLL boundaries.
This is a bug in upstream gcc: see
http://gcc.gnu.org/PR24196
I see...
The fix is almost - but not quite
Dave Korn:
Hi Dave,
Hi Jan, if you're currently around,
Thanks for the ping, I've been away.
It looks to me as if cygguile-17.dll needs to be rebuilt with an up-to-date
gcc with the fix for throwing strings across dll boundaries.
Hmm. It seems that gcc is at
install:
On 31 January 2008 16:05, Jan Nieuwenhuizen wrote:
Dave Korn:
Hi Dave,
Hi Jan, if you're currently around,
Thanks for the ping, I've been away.
Thanks for getting back to me!
It looks to me as if cygguile-17.dll needs to be rebuilt with an
up-to-date gcc with the fix for
20 matches
Mail list logo
