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

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

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

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

[-- Attachment #2: libiberty-cyghack-removal-patch.diff --]
[-- Type: application/octet-stream, Size: 1296 bytes --]

Index: libiberty/configure.ac
===================================================================
--- libiberty/configure.ac	(revision 143471)
+++ libiberty/configure.ac	(working copy)
@@ -571,29 +571,6 @@ if test -z "${setobjs}"; then
 
   case "${host}" in
 
-  *-*-cygwin*)
-    # The Cygwin library actually uses a couple of files from
-    # libiberty when it is built.  If we are building a native
-    # Cygwin, and we run the tests, we will appear to have these
-    # files.  However, when we go on to build winsup, we will wind up
-    # with a library which does not have the files, since they should
-    # have come from libiberty.
-
-    # We handle this by removing the functions the winsup library
-    # provides from our shell variables, so that they appear to be
-    # missing.
-
-    # DJ - only if we're *building* cygwin, not just building *with* cygwin
-  
-    if test -n "${with_target_subdir}"
-    then
-      funcs="`echo $funcs | sed -e 's/random//'`"
-      AC_LIBOBJ([random])
-      vars="`echo $vars | sed -e 's/sys_siglist//'`"
-      checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`"
-    fi
-    ;;
-
   *-*-mingw32*)
     # Under mingw32, sys_nerr and sys_errlist exist, but they are
     # macros, so the test below won't find them.

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]

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

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

[DJ Delorie]

>   Ok for HEAD of both gcc/ and src/ ?

Ok.

> libiberty/ChangeLog
> 
> 	* configure.ac (funcs, vars, checkfuncs):  Don't munge on Cygwin,
> 	as it no longer shares libiberty object files.
> 	* configure:  Regenerated.

Re: [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:
>>   Ok for HEAD of both gcc/ and src/ ?
>
> Ok.

  Thanks, applied.  I'm feeling lazy: there's still an auto-merger that'll
port it across to src/ for me, isn't there?

    cheers,
      DaveK

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

[DJ Delorie]

>   Thanks, applied.  I'm feeling lazy: there's still an auto-merger
> that'll port it across to src/ for me, isn't there?

Semi-automatic.  If you don't merge it, I have a cron job that does
everything but the "cvs commit" (and writes a script to do that, too).
I see the email and run the generated script to commit the actual
changes.

So if you're not in a rush, yes, I'll merge it eventually.  The script
runs once an hour, but that doesn't mean I'm watching it every hour ;-)

Re: [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:
>>   Thanks, applied.  I'm feeling lazy: there's still an auto-merger
>> that'll port it across to src/ for me, isn't there?
>
> Semi-automatic.

  Nah, then I won't trouble you; I've applied it to src/.

    cheers,
      DaveK.