headers
Christopher Faylor | 5 Jan 2009 16:52
Favicon

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
Permalink | Reply | 0 comments |
headers
Dave Korn | 18 Jan 2009 01:52

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

Permalink | Reply | 0 comments |
headers
Christopher Faylor | 18 Jan 2009 06:06
Favicon

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)

Permalink | Reply | 0 comments |
headers
Dave Korn | 18 Jan 2009 06:49

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)

Permalink | Reply | 0 comments |
headers
DJ Delorie | 18 Jan 2009 18:07
Picon
Favicon

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.
Permalink | Reply | 0 comments |
headers
Dave Korn | 18 Jan 2009 22:38

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
Permalink | Reply | 0 comments |
headers
DJ Delorie | 18 Jan 2009 22:57
Picon
Favicon

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 ;-)
Permalink | Reply | 0 comments |
headers
Dave Korn | 19 Jan 2009 00:13

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.
Permalink | Reply | 0 comments |

Gmane