Pierre A. Humblet | 5 Jan 16:19 2009
Picon

Re: [Patch] Make cygcheck handle Windows paths with spaces

Oops, I didn't notice that one line required a double fix.

Pierre

2009-01-05  Pierre Humblet  <Pierre.Humblet <at> ieee.org>

        * cygcheck.cc (dump_sysinfo_services): Quote the path for popen.

Index: cygcheck.cc
===================================================================
RCS file: /cvs/src/src/winsup/utils/cygcheck.cc,v
retrieving revision 1.106
diff -u -p -r1.106 cygcheck.cc
--- cygcheck.cc 31 Dec 2008 01:44:36 -0000      1.106
+++ cygcheck.cc 5 Jan 2009 15:05:56 -0000
 <at>  <at>  -1137,7 +1137,7  <at>  <at>  dump_sysinfo_services ()
   /* For verbose mode, just run cygrunsrv --list --verbose and copy output
      verbatim; otherwise run cygrunsrv --list and then cygrunsrv --query for
      each service.  */
-  snprintf (buf, sizeof (buf), (verbose ? "\"%s\" --list --verbose" : "%s --list"),
+  snprintf (buf, sizeof (buf), (verbose ? "\"%s\" --list --verbose" : "\"%s\" --list"),
            cygrunsrv);
   if ((f = popen (buf, "rt")) == NULL)
     {

----- Original Message ----- 
From: "Pierre A. Humblet" <pierre <at> phumblet.no-ip.org>
To: <cygwin-patches <at> cygwin.com>
Sent: Tuesday, December 30, 2008 3:14 PM
Subject: [Patch] Make cygcheck handle Window paths with spaces
(Continue reading)

Christopher Faylor | 5 Jan 16:52 2009

Re: [Patch] Make cygcheck handle Windows paths with spaces

On Mon, Jan 05, 2009 at 10:19:59AM -0500, Pierre A. Humblet wrote:
>Oops, I didn't notice that one line required a double fix.
>
>Pierre
>
>2009-01-05  Pierre Humblet  <Pierre.Humblet <at> ieee.org>
> 
>        * cygcheck.cc (dump_sysinfo_services): Quote the path for popen.

Looks good.  Please check in.

Thanks.

cgf

Dave Korn | 18 Jan 01:52 2009

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

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.
(Continue reading)

Christopher Faylor | 18 Jan 06:06 2009

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

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
>
(Continue reading)

Dave Korn | 18 Jan 06:49 2009

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

[Cc list trimmed]
Christopher Faylor wrote:
> On Sun, Jan 18, 2009 at 12:52:14AM +0000, Dave Korn wrote:
>> I've tested
>> this by doing (separate) native builds of GCC, winsup,
                                                  ^^^^^^ :P see below!

>> 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.

  Thanks, I thought it would be the right thing to do.  Just waiting on DJ or
ILT's approval now.

> 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.

  Yep, I discovered that you removed it from the winsup module definition, I
only "tested" it for a winsup build (as mentioned above) because I had an old
source tree that still had it there by accident of "cvs -dP" not removing
(Continue reading)

DJ Delorie | 18 Jan 18:07 2009
Picon

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


>   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.

Dave Korn | 18 Jan 22:38 2009

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 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

DJ Delorie | 18 Jan 22:57 2009
Picon

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


>   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 ;-)

Dave Korn | 19 Jan 00:13 2009

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 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.


Gmane