[PATCH] support for mingw-w64
sezeroz at gmail.com
Sun Sep 13 00:33:41 CEST 2009
On Sun, Sep 13, 2009 at 12:00 AM, Torbjorn Granlund <tg at gmplib.org> wrote:
> Ozkan Sezer <sezeroz at gmail.com> writes:
> I replaced the necessary parts of my old draft with your patch,
> building and testing seems to work just fine. See the attached
> w64-2.patch as a reference to see what I did (it is for reference
> only, doesn't include diffs to generated files, discussed further
> below). See the attached test.log file for test results.
> One failure is t-locale: You are replacing the glibc library
> function with yours, so the linkage fails because of multiple
> definitions of localeconv. If I replace #if HAVE_LOCALECONV
> with #if HAVE_LOCALECONV && !defined(__MINGW32__)
> in t-locale.c, then build succeeds, and I get "Test skipped,
> replacing localeconv/nl_langinfo doesn't work".
> Is __MINGW32__ defined for __MINGW64__? Isn't there an __MINGW64__
> symbol we should use instead, if we choose your workaround?
__MINGW32__ is defined for both mingw.org and for mingw-w64.
For mingw-w64, __MINGW64__ is defined, too, when targetting
> It seem strange that we're not allowed to override localeconv. Is this
> some strange windoze-ism, that libraries are linked in as a unit, not
> incrementally from undefined symbols?
> I've never heard of this problem in mingw32, by the way.
I just forwarded this to Kai Tietz. Waiting for his answer and
will return with it to you as soon as I can.
> There are 5 warnings from the test build procedure:
> memory.c: In function 'tests_reallocate':
> memory.c:113: warning: cast from pointer to integer of different size
> memory.c:121: warning: cast from pointer to integer of different size
> memory.c: In function 'tests_free_find':
> memory.c:168: warning: cast from pointer to integer of different size
> t-get_str.c: In function 'check_one':
> t-get_str.c:68: warning: cast from pointer to integer of different size
> t-get_str.c:69: warning: cast from pointer to integer of different size
> My humble suggestion would be replacing those 0x%lX simply
> with %p (attached: tests.patch).
> Is %p part of ISO C90? I suppose these are error messages, to poor
IIRC, it is. Gcc doesn't warn at all if I compile %p with -std=c89.
> printing results are no disaster. But we should handle C90 right even
Only that the printed address will be truncated, but yes,
> As for my patching configure.in at the correct location: Well,
> I thought that I already did it at the correct place, where you
> do your stuff for athlon64 | x86_64 cpus. Well, I just saw that
> I missed the atom cpu case, I think.. What is your suggestion
> about the correct place in configure.in?
> Look for a case statement indexed by "operating system" within the x86
> stuff. Add a new tag there, put your code after that tag.
The best place I could fit myself was your existing mingw
mingw case. Is the following acceptable for configure.in
--- gmp-4.3.1/configure.in 2009-05-12 09:12:12.000000000 +0300
+++ gmp/configure.in 2009-09-13 01:28:22.000000000 +0300
@@ -1532,13 +1532,20 @@ esac
# mingw can be built by the cygwin gcc if -mno-cygwin is added. For
# convenience add this automatically if it works. Actual mingw gcc accepts
-# -mno-cygwin too, but of course is the default. mingw only runs on the
-# x86s, but allow any CPU here so as to catch "none" too.
+# -mno-cygwin too, but of course is the default. Allow any CPU here so as
+# to catch "none" too.
+# Win64 follows LLP64, not LP64, therefore long is only 32 bit. We should
+# use long long for mingw-w64. We don't use our 64 bit assembly for win64,
+# either, because win64 ABI is different.
case $host in
+ # silence many pedantic warnings for w64:
+ gcc_64_cflags="$gcc_64_cflags -std=gnu99"
More information about the gmp-devel