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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Dave Korn-6
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

libiberty-cyghack-removal-patch.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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-9
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
Reply | Threaded
Open this post in threaded view
|

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-6
[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
subdirectories that only get changed in the modules list.  In a fresh checkout
there's nothing to test!

    cheers,
      DaveK
Reply | Threaded
Open this post in threaded view
|

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-2
In reply to this post by Dave Korn-6

>   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.
Reply | Threaded
Open this post in threaded view
|

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-6
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
Reply | Threaded
Open this post in threaded view
|

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

>   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 ;-)
Reply | Threaded
Open this post in threaded view
|

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