RE: PING Jan Nieuwenhuizen re libguile17
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 gcc-4.2.3 but all have the same segfault in autogen. Jan, please just to clarify: did you build the actual release version of libguile with gcc4? Yes, plain 1.8.2. I don't recommend using gcc 4 series for production releases yet. I know, but for all my packages it seemed to work for years now... Is there some specific problem in building lilypond that is resolved by using gcc 4? I'm investigating this. It's quite tricky, currently LilyPond itself does not compile using gcc-4.2.3, but we do have success reports with 4.3.0. 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? Unpacking Cygwin's gcc/g++ source archive in a python script is a bit of a pain (that's an understatement :-). (I'm also working in the background on an experimental gcc 4 package). That would be nice. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: gmp-4.2.2-1 and and mpfr- for upload
Charles Wilson wrote: 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 The new 4.2.2-1 cyggmpxx3.dll is AFAICT binary compatible with the current 4.2.1-1 release. The changes are quite small and I ran the 4.2.1-1 testsuite with the 4.2.2-1 DLL without problem. I don't have strong feelings about this change, but we will have to bump the C++ library version when we move to gcc-4. I thought it excessive to change it now for no real reason. According to http://gmplib.org/ - Additional issues with GMP 4.2: The solib numbers for the shared version of libgmp and libgmpxx are very wrong, making them appear older than version 4.1.4. David
RE: PING Jan Nieuwenhuizen re libguile17
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. the latest release in the distro. 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? (I'm also working in the background on an experimental gcc 4 package). That would be nice. Dwarf2 debug and exceptions, shared libgcc. Seems to mostly work but the testsuite's still running (since sunday!). Two libstdc++ regressions showed up so far, g++ clean, gcc still running. cheers, DaveK -- Can't think of a witty .sigline today
RE: PING Jan Nieuwenhuizen re libguile17
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? Releases are not so often that it is annoying, I manually repacked them. But still. When working with computers, people find it handy to automate repetitive tasks, such as cross-building a whole dependency-tree of packages for a number of platforms. Python is a handy tool to automate such a task, which is what we have done in GUB (LilyPond's Grand Unified Builder). Tracking upstream's sources currently works easily with tarballs, CVS, GIT, bazaar and subversion. Only Cygwin's [gcc] source archives are a bit of a challenge ;-) Greetings, Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
RE: PING Jan Nieuwenhuizen re libguile17
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 archive in a python script is a bit of a pain (that's an understatement :-). I don't understand why that would be necessary? Releases are not so often that it is annoying, I manually repacked them. But still. When working with computers, people find it handy to automate repetitive tasks Is this meant to be as offensively patronising as it came out? It reads like it was aimed at a two-year old child. If I want the Janet and John guide to computer fundamentals, I'll ask for it. cheers, DaveK -- Can't think of a witty .sigline today
[ITP] VOTE: grub 1.96-1 [experimental]
I would like to contribute my Cygwin port of the boot manager GRUB2. (http://www.gnu.org/software/grub/grub-2.en.html) http://franke.dvrdns.org/cygwin/release/grub/grub-1.96-1.tar.bz2 http://franke.dvrdns.org/cygwin/release/grub/grub-1.96-1-src.tar.bz2 http://franke.dvrdns.org/cygwin/release/grub/setup.hint This package is based on upstream CVS snapshot from 2008-03-26. GRUB2 is included in Debian testing and in the backports for Debian stable: http://packages.debian.org/lenny/grub-pc http://packages.debian.org/etch-backports/grub-pc Christian
Re: [ITP] VOTE: grub 1.96-1 [experimental]
Christian Franke wrote: I would like to contribute my Cygwin port of the boot manager GRUB2. (http://www.gnu.org/software/grub/grub-2.en.html) Is anybody else as confused as I am? How in the world can you have a *boot manager* ported to cygwin? Cygwin requires the host Windows OS to be up and running; it has nothing to do with pre-OS bootloader operations... Unless I'm really missing something here, I don't think this is an appropriate candidate for the cygwin distro -- but I'm open to persuasion if somebody can kindly explain how cygwin-grub2 could POSSIBLY be of any use at all... -1 -- Chuck
