[PATCH] Build libgcc_s on Windows

Charles Wilson cygwin@cwilson.fastmail.fm
Mon Aug 25 07:40:00 GMT 2008


Paolo Bonzini wrote:
> 
>> I just saw Paolo's message Tue, 19 Aug 2008 17:54:59 +0200; I'm not sure
>> how his suggestions might modify this one...
> 
> It just removes the need for sed'ing out SHLIB_SONAME.
> 
> I like your plan.
> 
> I think we should split in three parts.  First is what Aaron has, second
> is what I suggested, last is what you suggested.  Note that my part can
> be tested on Linux (which is cheaper).

So does that mean Aaron's patch has all necessary approvals to be pushed
as-is?  From re-reading the thread, I see:

Danny Smith:
> OK from this Windows maintainer, but wait for Dave Korn to comment.
and
> While your at it you may as well clean up the use of
> GetModuleHandle/GetProcAddress to get  in cygming-crtbegin.

a) Dave hasn't commented yet.
b) it's not clear whether Danny meant for the cygming-crtbegin cleanup
to be part of this patch required before push, or if he meant this patch
is ok but Aaron should post a separate patch later for cygming-crtbegin.

Then yours [Paolo]:
>  <toplevel>
>  Ok, but you forgot a piece of a comment in configure.ac.

I haven't seen a revised patch that addresses this.

[Paolo]:
>  <gcc> / mkmap related stuff
>  Right. I guess your patch is then okay from this build maintainer.

But then you [Paolo] have
> I think we should split in three parts. First is what Aaron has,

as-is?

> second is what I suggested

I assume you mean this bit:

>  ... [replace ugly code with]
>  $(call replace_shlib_vars,SOME_BASE_NAME,$(SOME_VAR))
>  using an auxiliary variable definition like this one: [etc.]

as a followon patch?

> last is what you [Charles] suggested.

as yet another, separate patch?

So at best, that's
1) wait for Dave to comment
2) fix the missing comment in <toplevel>/configure.ac
and then push, followed by

patch-1) Danny's requested cleanups to cygming-crtbegin
patch-2) the SHLIB_MKMAP_OPTS stuff $(call replace ...)
patch-3) something along the lines of what I proposed

where patch-3 must wait until patch-2, but patch-1 is independent of
both patch-2 and patch-3.

Can we get all of that in before stage-1 closes, or is some of it
acceptable in stage-3?

--
Chuck



More information about the Gcc-patches mailing list