Hi Martin, ---- 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, 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. 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. > > 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
