[Mingw-w64-public] [PATCH] Remove reference to strnlen from msvcrt.def
Hi, We recently received some bug reports that executables compiled with mingw-w64 couldn't be executed on Windows XP environments. Users would get fatal error messages which indicate that the symbol strnlen couldn't be found in msvcrt.dll (which is correct for Windows XP). I've verified this with Dependency Walker and some binaries indeed were under the assumption that strnlen is part of msvcrt.dll. This is odd as the mingw-w64 crt contains a wrapper implementation for strnlen (in order to fix these Windows XP compatibility issues). So I investigated further and found out that strnlen is still being referenced in the msvcrt.def files. As other wrapped symbols are also commented out in msvcrt.def I got the impression that wrapped symbols should be removed from msvcrt.def. I did this for strnlen in my local test environment and it indeed caused the strnlen in msvcrt.dll dependency to disappear from compiled binaries. Is this patch the correct solution to fixing this issue or do you think the real cause is somewhere else? Regards, Erik van Pienbroek >From a289e2cf5e9f158b861612ceb047a35a2b523c98 Mon Sep 17 00:00:00 2001 From: Erik van Pienbroek Date: Thu, 18 Jul 2013 21:35:11 +0200 Subject: [PATCH] Remove reference to strnlen from msvcrt.def The symbol strnlen is missing from msvcrt.dll in Windows XP. Therefore a wrapper function was added to the crt in r3513 to fix compatibility with Windows XP, but the msvcrt.def file wasn't updated to reflect this. Therefore compiled binaries could still be under the assumption that the strnlen always is part of msvcrt.dll and cause runtime problems on Windows XP --- mingw-w64-crt/lib32/msvcrt.def.in | 2 +- mingw-w64-crt/lib64/msvcrt.def.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/mingw-w64-crt/lib32/msvcrt.def.in b/mingw-w64-crt/lib32/msvcrt.def.in index ad8ec29..3fb17eb 100644 --- a/mingw-w64-crt/lib32/msvcrt.def.in +++ b/mingw-w64-crt/lib32/msvcrt.def.in @@ -1205,7 +1205,7 @@ strcpy_s strerror_s strncat_s strncpy_s -strnlen DATA ; msvcrt in XP and lower doesn't have this +; strnlen replaced by emu strtok_s swprintf_s swscanf_s diff --git a/mingw-w64-crt/lib64/msvcrt.def.in b/mingw-w64-crt/lib64/msvcrt.def.in index 14f6083..ed81eff 100644 --- a/mingw-w64-crt/lib64/msvcrt.def.in +++ b/mingw-w64-crt/lib64/msvcrt.def.in @@ -1198,7 +1198,7 @@ strncat_s strncmp strncpy strncpy_s -strnlen DATA ; msvcrt in XP and lower doesn't have this +; strnlen replaced by emu strpbrk strrchr strspn -- 1.8.3.1 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Remove reference to strnlen from msvcrt.def
Hello, Le 18/07/2013 21:49, Erik van Pienbroek a écrit : > Hi, > > We recently received some bug reports that executables compiled with > mingw-w64 couldn't be executed on Windows XP environments. Users > would get fatal error messages which indicate that the symbol strnlen > couldn't be found in msvcrt.dll (which is correct for Windows XP). > > I've verified this with Dependency Walker and some binaries > indeed were under the assumption that strnlen is part of msvcrt.dll. > > This is odd as the mingw-w64 crt contains a wrapper implementation > for strnlen (in order to fix these Windows XP compatibility issues). So > I investigated further and found out that strnlen is still being > referenced in the msvcrt.def files. > > As other wrapped symbols are also commented out in msvcrt.def I got the > impression that wrapped symbols should be removed from msvcrt.def. I did > this for strnlen in my local test environment and it indeed caused the > strnlen in msvcrt.dll dependency to disappear from compiled binaries. > > Is this patch the correct solution to fixing this issue or do you think > the real cause is somewhere else? I will let Kai confirm but your patch looks ok to me! > Regards, > > Erik van Pienbroek -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Remove reference to strnlen from msvcrt.def
I am not able your patch the next two weeks. If Jacek, Ozkan, or dw confirm, then patch is oj for appkay. Kai Am 18.07.2013 10:14 schrieb "Rafaël Carré" : > Hello, > > Le 18/07/2013 21:49, Erik van Pienbroek a écrit : > > Hi, > > > > We recently received some bug reports that executables compiled with > > mingw-w64 couldn't be executed on Windows XP environments. Users > > would get fatal error messages which indicate that the symbol strnlen > > couldn't be found in msvcrt.dll (which is correct for Windows XP). > > > > I've verified this with Dependency Walker and some binaries > > indeed were under the assumption that strnlen is part of msvcrt.dll. > > > > This is odd as the mingw-w64 crt contains a wrapper implementation > > for strnlen (in order to fix these Windows XP compatibility issues). So > > I investigated further and found out that strnlen is still being > > referenced in the msvcrt.def files. > > > > As other wrapped symbols are also commented out in msvcrt.def I got the > > impression that wrapped symbols should be removed from msvcrt.def. I did > > this for strnlen in my local test environment and it indeed caused the > > strnlen in msvcrt.dll dependency to disappear from compiled binaries. > > > > Is this patch the correct solution to fixing this issue or do you think > > the real cause is somewhere else? > > I will let Kai confirm but your patch looks ok to me! > > > Regards, > > > > Erik van Pienbroek > > > -- > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Remove reference to strnlen from msvcrt.def
On Fri, Jul 19, 2013 at 4:16 AM, Kai Tietz wrote: > I am not able your patch the next two weeks. If Jacek, Ozkan, or dw > confirm, then patch is oj for appkay. > > Kai > > Am 18.07.2013 10:14 schrieb "Rafaël Carré" : >> >> Hello, >> >> Le 18/07/2013 21:49, Erik van Pienbroek a écrit : >> > Hi, >> > >> > We recently received some bug reports that executables compiled with >> > mingw-w64 couldn't be executed on Windows XP environments. Users >> > would get fatal error messages which indicate that the symbol strnlen >> > couldn't be found in msvcrt.dll (which is correct for Windows XP). >> > >> > I've verified this with Dependency Walker and some binaries >> > indeed were under the assumption that strnlen is part of msvcrt.dll. >> > >> > This is odd as the mingw-w64 crt contains a wrapper implementation >> > for strnlen (in order to fix these Windows XP compatibility issues). So >> > I investigated further and found out that strnlen is still being >> > referenced in the msvcrt.def files. >> > >> > As other wrapped symbols are also commented out in msvcrt.def I got the >> > impression that wrapped symbols should be removed from msvcrt.def. I did >> > this for strnlen in my local test environment and it indeed caused the >> > strnlen in msvcrt.dll dependency to disappear from compiled binaries. >> > >> > Is this patch the correct solution to fixing this issue or do you think >> > the real cause is somewhere else? >> >> I will let Kai confirm but your patch looks ok to me! >> >> > Regards, >> > >> > Erik van Pienbroek >> > The patch doesn't seem right to me: it is removing a symbol marked as DATA, therefore the mingw-w64-compiled code should have this symbol imported from msvcrt.dll but do so from libmingwex. The only way this symbol goes into mingw-compiled code is that it has a foreign symbol compiled by e.g. msvc? What am I missing? -- O.S. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Remove reference to strnlen from msvcrt.def
On 07/19/13 07:43, Ozkan Sezer wrote: > On Fri, Jul 19, 2013 at 4:16 AM, Kai Tietz wrote: >> I am not able your patch the next two weeks. If Jacek, Ozkan, or dw >> confirm, then patch is oj for appkay. Looks good to me. Ideally, we should move that to libmsvcrt.a like some other functions, but that may be done later. > The patch doesn't seem right to me: it is removing a symbol marked > as DATA, therefore the mingw-w64-compiled code should have this > symbol imported from msvcrt.dll but do so from libmingwex. The only > way this symbol goes into mingw-compiled code is that it has a > foreign symbol compiled by e.g. msvc? What am I missing? We don't use _CRTIMP for that function in headers, so DATA symbol matches what imported one. Cheers, Jacek -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
