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