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?

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.

To elaborate; before commit 2146d75d7fd027118fe267f2a8fb139bcab6a9b8, all architectures had separate def files for msvcrt.dll. Neither lib32 nor lib64 had _wassert at all, only libarm32. In 2146d75d7fd027118fe267f2a8fb139bcab6a9b8 and 0360917119ad3f09635d75103b6dba859cfe0c93 I merged all of them into one, but I did a mistake of exposing more functions than before - I assumed that this wouldn't be an issue except for people. This caused issues where the built binaries wouldn't run on XP any longer (msvcrt.a has got compatibility fallbacks for some functions, but exposing them in the def file ended up linking directly to the function in msvcrt.dll.

In 1035bed24e833ea5eb487c78f4f350ea48f31e8b I tried to fix this mistake; after this commit, libmsvcrt.a should contains pretty much exactly what it did before I started touching it, trying to fix what I broke.

For _wassert; indeed, all versions of msvcrt.dll even back to XP contains this function. But since mingw-w64 has got their own version in libmingwex, we shouldn't expose the function in the def file. The reason it's exposed for arm is only that I tried to mimic exactly what the def files had before I started touching it; in case someone tries to do the same as you for arm, they would probably end up with the same issue, so we should probably remove that function from there as well.

I'm dubious about this patch as all of these F_ARM_ANY'ed values are also
available on x86, this is causing an annoying linking problem. As I want to 
link to the
msvcrt functions first and only mingwex for the extensions it provides.

As for why a lot of other functions are flagged F_ARM_ANY; they might be functions that exist in modern versions of msvcrt.dll but not in the baseline XP version. Since windows on arm (windows phone) only exists corresponding to windows 8 and newer, it's ok to expose all functions that existed in that baseline version for arm, while we want to hide them (and fall back on compatibility wrappers) for 32 bit x86 where XP compatibility still is maintained.


So in short, after all the commits I did on libmsvcrt.a lately, it should now be pretty much exactly as it was before - these functions were omitted for one reason or another (some for more or less tricky compatibility workarounds) earlier in the project history. It's just the arm side that is newer that so far exports much more, but with more use, actually might end up tweaked closer to the x86 versions.

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

Reply via email to