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. cheers, DaveK
libiberty-cyghack-removal-patch.diff
Description: Binary data