[PATCH/libiberty] Fix PR38903 Cygwin GCC bootstrap failure [was Re: Libiberty issue vs cygwin [was Re: This is a Cygwin failure yeah?]]
Sun Jan 18 01:14:00 GMT 2009
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/ ?
* configure.ac (funcs, vars, checkfuncs): Don't munge on Cygwin,
as it no longer shares libiberty object files.
* configure: Regenerated.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1296 bytes
Desc: not available
More information about the Gcc-patches