RE: PING Jan Nieuwenhuizen re libguile17
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 gcc-4.0.4; with some luck that's new enough for LilyPond and still binary compatible Cygwin. Jan. 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. Jan, please just to clarify: did you build the actual release version of libguile with gcc4? I couldn't tell from the context whether you were only using it to try the --enable-fully-dynamic-string experiment. I don't recommend using gcc 4 series for production releases yet. There was a lot of instability after the change to tree-ssa infrastructure and both 4.0 and 4.1 series had a big bunch of regressions. (I think it's starting to get there with the 4.2 and 4.3 series and that's why I'm I would *strongly* recommend all maintainers stick with the official release of the compiler when building packages for the distro. It's the same version the DLL is built with; we should use it for the apps too. C is /supposed/ to be ABI-compatible, but as we've discovered, it's not always as simple as that. Using the exact same compiler for the DLL and the packages means we've got one less thing that can go wrong. Is there some specific problem in building lilypond that is resolved by using gcc 4? 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. (I'm also working in the background on an experimental gcc 4 package). cheers, DaveK -- Can't think of a witty .sigline today
RE: gmp-4.2.2-1 and and mpfr- for upload
David Billinghurst wrote on 24 March 2008 03:43: The version number of libgmpxx was bumped in the upstream files to correct the shared library numbers. I reverted this change in the cygwin build as the cygwin shared library is backwards compatible with gmp-4.2.1 - the 4.2.1 testsuite passes with the new cyggmpxx-3.dll. On the face of it, that sounds like a worryingly dubious idea. cheers, DaveK -- Can't think of a witty .sigline today
Re: gmp-4.2.2-1 and and mpfr- for upload
Dave Korn wrote: David Billinghurst wrote on 24 March 2008 03:43: The version number of libgmpxx was bumped in the upstream files to correct the shared library numbers. I reverted this change in the cygwin build as the cygwin shared library is backwards compatible with gmp-4.2.1 - the 4.2.1 testsuite passes with the new cyggmpxx-3.dll. On the face of it, that sounds like a worryingly dubious idea. Not necessarily. It is often the case that the version number of cygwin's library ports (I don't want to say cygwin DLL because that could be misconstrued) do not exactly follow the upstream versioning. Most of the time, it's because there have been cygwin-specific changes that have forced our version number ahead of the upstream progression. Take ncurses, for instance: upstream so's are at version 5.0 or so, but our DLL number is 8. In rare cases, we might fall behind the upstream numbers -- imagine if an ABI change occurred, but only #ifdef SOLARIS -- there'd be no reason (other than a desire for consistency) to bump the cygwin port's DLL number. However, in the case of gmp, it is probably necessary to understand WHY the upstream maintainers bumped the DLL number. Did they make a back-wards incompatible change sometime early in the -3 sequence, but neglected to update the number until now? Or is the new version number merely cosmetic? correct the shared library numbers just doesn't provide enough information. -- Chuck
