[PATCH/libiberty] Fix PR38903 Cygwin GCC bootstrap failure [was Re: Libiberty issue vs cygwin [was Re: This is a Cygwin failure yeah?]]

[Dave Korn]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libiberty-cyghack-removal-patch.diff
Type: application/octet-stream
Size: 1296 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-patches/attachments/20090118/ca88acec/attachment.obj>