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
