---- On Sun, 22 Oct 2017 21:29:32 +0000 Martin Storsjö <[email protected]>
wrote ----
> On Sun, 22 Oct 2017, Tamar Christina wrote:
>
> > ---- On Sun, 22 Oct 2017 19:28:04 +0000 Martin Storsjö <[email protected]>
> > wrote ----
> > > On Sun, 22 Oct 2017, Tamar Christina wrote:
> > >
> > > > Actually..
> > > >
> > > > This may not be the right fix. The regression I am trying to fix is a
> > > > duplicate symbols error on _wassert when
> > > > linking both mscvrt and mingwex. But I now see that:
> > > >
> > > > commit 1035bed24e833ea5eb487c78f4f350ea48f31e8b
> > > > Author: Martin Storsjö <[email protected]>
> > > > Date: Fri Sep 29 12:42:59 2017 +0300
> > > >
> > > > crt: More strictly flag functions in the unified msvcrt.def.in
> > > >
> > > > Now the output from the unified msvcrt.def.in should be almost
> > > > identical
> > > > to what it was before, except for some new *_dbg and __p_*
> > > > functions.
> > > >
> > > > The functions that were included for 32 and 64 bit x86 in the
> > > > unification
> > > > were originally believed to be harmless, but some of them turned
> > > > out to
> > > > be function that we have compatibility fallbacks for, that were
> > > > missed
> > > > when libmsvcrt.a suddenly started exporting them. This broke
> > > > compatibility
> > > > with XP in some cases.
> > > >
> > > > Signed-off-by: Martin Storsjö <[email protected]>
> > > >
> > > > added the change
> > > >
> > > > -_wassert
> > > > +F_ARM_ANY(_wassert)
> > > >
> > > > and I don't know why... it's there on x86 as well.
> > >
> > > The issure you're seeing, is that when you've built with the absolutely
> > > latest master version that includes this commit?
> >
> > I first noticed it when I just upgraded the ones in msys2, later I built
> > from master
> > myself.
> >
> > >
> > > Because if the issue you're seeing is duplicate symbols between msvcrt
> > > and
> > > mingwex, it doesn't sound like you have this commit, this commit
> > > actually
> > > would fix it.
> >
> > Hmm, but this commit hides _wassert
> >
> > say I have an object file requiring both _assert and _wassert.
> >
> > if my link order is -lmsvcrt -lmingwex, it'll pick assert from msvcrt,
>
> It shouldn't pick _assert from msvcrt as far as I can see. Since _assert
> in msvcrt.def.in is defined with DATA; it will only produce an
> __imp__assert symbol, not _assert. When I try this exact setup you're
> describing, I don't get any error even though I link -lmsvcrt before
> -lmingwex.
You're right, it is DATA. Hmm I'm not sure when the msys2 snapshot was made but
you're correct that master even without my patch works..
Sorry for the noise!
>
> What form of the symbol does your object file refer to, _assert or
> __imp__assert?
>
> > and then pick _wassert from mingwex, but because in mingwex both
> > _assert and _wassert live in the same unit, when it loads the object file
> > for
> > linking it has no choice but to error out on the duplicate definition for
> > _assert.
> >
> > The first path I submitted "solves" this by splitting the functions off
> > into different units since they're
> > independent anyway.
> >
> > So if you're saying your patch brings things back to how they were before,
> > I don't quite understand what happened..
> > though I didn't go back very far in the history.
>
> I would appreciate if you can crosscheck and test both before
> 2146d75d7fd027118fe267f2a8fb139bcab6a9b8 (before I first touched msvcrt)
> and after 1035bed24e833ea5eb487c78f4f350ea48f31e8b (when things should be
> fixed); I'm sure that you got errors about duplicate definitions of
> _wassert within that commit range though.
>
> > Currently the only way to use both _assert and _wassert is to link mingwex
> > first, and this didn't used to be the case
> > c.a gcc 6.2 release time.
> >
> > Given that you say they don't exist on XP, then maybe my original patch
> > is the right approach after all.
>
> I didn't say that these don't exist on XP - they do.
>
> I don't know and haven't dug through all of the source history to figure
> out the exact reasoning for the mingw version of these functions (perhaps
> these functions didn't exist on win2k, mingw added a function of their
> own, which isn't necessary now once XP is the baseline?). I've just tried
> to maintain/restore the exact original behaviour, whatever that was, as
> well as possible while refactoring these files.
>
> // Martin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
