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

[Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>]

On Sun, Jan 18, 2009 at 12:52:14AM +0000, 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