Package: mingw-w64-dev
Version: 1.0+20101003-1
Severity: normal
Tags: patch
Executables produced by recent mingw fail on start on win2k and XP sp0
with a message "___lc_codepage_func in DLL msvcrt.dll" .
This regression is introduced in SVN revision 2285:
Author: jon_y
Date: Sun May 2 10:32:30 2010 +0000
use ___lc_codepage_func instead of __lc_codepage to get codepage.
diff --git a/mingw-w64-crt/misc/mb_wc_common.h
b/mingw-w64-crt/misc/mb_wc_common.h
index af633b8..50794ea 100644
--- a/mingw-w64-crt/misc/mb_wc_common.h
+++ b/mingw-w64-crt/misc/mb_wc_common.h
@@ -4,11 +4,11 @@
* No warranty is given; refer to the file DISCLAIMER.PD within this package.
*/
-#undef __lc_codepage
-__declspec(dllimport) extern unsigned int __lc_codepage;
+#include <_mingw.h>
+_CRTIMP unsigned int ___lc_codepage_func(void);
static inline
unsigned int get_codepage (void)
{
- return __lc_codepage;
+ return ___lc_codepage_func();
}
This change is trivially revertable, and if you do so, executables start to
work again. It would be better to use one of proper win32 locale handling
functions rather than undocumented __lc_codepage or __lc_codepage_func(),
but that's better decided by upstream; simple reversion of this patch is
more conservative.
I tried reporting this on upstream's bug tracker, but they use SourceForge
which is as usually broken, throwing an error whenever I try to log in.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- no debconf information
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
