Re: [PATCH/libiberty] Fix PR38903 Cygwin GCC bootstrap failure [was Re: Libiberty issue vs cygwin [was Re: This is a Cygwin failure yeah?]]
Ok for HEAD of both gcc/ and src/ ? Ok. libiberty/ChangeLog * configure.ac (funcs, vars, checkfuncs): Don't munge on Cygwin, as it no longer shares libiberty object files. * configure: Regenerated.
Re: [PATCH/libiberty] Fix PR38903 Cygwin GCC bootstrap failure [was Re: Libiberty issue vs cygwin [was Re: This is a Cygwin failure yeah?]]
On Sun, Jan 18, 2009 at 12:52:14AM +, Dave Korn wrote: DJ Delorie wrote: IIRC, that whole clause was because cygwin's dll itself linked with libiberty, so the auto-detect stuff needed an override to make sure the right files were there when you build cygwin1.dll. Otherwise, it would detect that cygwin had strsignal, not build it, then fail later when cygwin1.dll couldn't find strsignal. If cygwin no longer links with libiberty, that whole clause can probably go away now. As it's target-specific, I'm OK with letting the target maintainers have the last word about it, too. There are no longer any references to ../libiberty/* in Cygwin's Makefile, and indeed the libiberty subdir has been removed from the module definition for winsup so you don't even get it in a fresh checkout any more. Given that, I think we can remove the clause entirely. I've tested this by doing (separate) native builds of GCC, winsup, binutils and GDB, with no issues arising. I haven't tried cross-builds or combined source-tree builds, but there's no reason to believe they would be affected any differently. GCC is in stage 4, but this is target-specific and fixes a bootstrap failure on a secondary platform. Ok for HEAD of both gcc/ and src/ ? libiberty/ChangeLog * configure.ac (funcs, vars, checkfuncs): Don't munge on Cygwin, as it no longer shares libiberty object files. * configure: Regenerated. Just in case you need confirmation: this looks fine. I removed the dependence on libiberty a while ago partially because, AFAICT, it actually subverted Red Hat's claim of owning all source code in Cygwin. You can't really say that if there are pure FSF GPLed or LGPLed pieces. cgf
Re: [PATCH/libiberty] Fix PR38903 Cygwin GCC bootstrap failure [was Re: Libiberty issue vs cygwin [was Re: This is a Cygwin failure yeah?]]
[Cc list trimmed] Christopher Faylor wrote: On Sun, Jan 18, 2009 at 12:52:14AM +, Dave Korn wrote: I've tested this by doing (separate) native builds of GCC, winsup, ^^ :P see below! GCC is in stage 4, but this is target-specific and fixes a bootstrap failure on a secondary platform. Ok for HEAD of both gcc/ and src/ ? libiberty/ChangeLog * configure.ac (funcs, vars, checkfuncs): Don't munge on Cygwin, as it no longer shares libiberty object files. * configure: Regenerated. Just in case you need confirmation: this looks fine. Thanks, I thought it would be the right thing to do. Just waiting on DJ or ILT's approval now. I removed the dependence on libiberty a while ago partially because, AFAICT, it actually subverted Red Hat's claim of owning all source code in Cygwin. You can't really say that if there are pure FSF GPLed or LGPLed pieces. Yep, I discovered that you removed it from the winsup module definition, I only tested it for a winsup build (as mentioned above) because I had an old source tree that still had it there by accident of cvs -dP not removing subdirectories that only get changed in the modules list. In a fresh checkout there's nothing to test! cheers, DaveK
