On Jul 22 13:59, Jon TURNEY wrote:
> On 22/07/2014 09:27, Corinna Vinschen wrote:
> >On Jul 17 20:24, Corinna Vinschen wrote:
> >>On Jul 17 16:31, Jon TURNEY wrote:
> >>>On 17/07/2014 08:37, Corinna Vinschen wrote:
> >>>>It's the libgcc DLL which gives us grief, so a new libgcc package is
> >>>>sufficent, afaics.  We should check if this DLL fixes the problem and
> >>>>then make it "curr" soon, I think.
> >>>
> >>>I briefly tested this other patch with my test case from the mail above, and
> >>>it doesn't seem to help.
> >>>[...]
> >>I asked DJ to take another look, but I guess ultimately we need the
> >>attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
> >>unavailable right now, unfortunately.
> >
> >Looks like I totally misunderstood DJ's patch.  The patch does *not*
> >change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file
> >which is statically linked into the executable.
> >
> >That means, to fix the issue, you don't have to replace libgcc, you
> >have to recompile the executable against the new crtbegin.o.
> >
> >DJ still claims his patch is the correct one.  The simple testcase
> >dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to
> >him.
> 
> Sorry, I hadn't tested it correctly.

No worries, this was my fault.  Talking about building a new libgcc
rather than building a new crtbegin.o was bound to lead everyone
off track :|

> Building my test with an updated crtbegin.o as well, my test case is fixed.

Nice!

> I agree this patch seems better than my suggested one, as it makes crtbegin
> do the right thing in the face of unbalanced libgcc load/unload, rather than
> attempting to balance the libgcc load/unload as mine does.

Ok.  I CC'ed DJ so he knows all is good, and then we probably need a
windows GCC maintainer to approve the patch I guess.  Kai?  Ping?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat