[PATCH] support for mingw-w64

[Ozkan Sezer]

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
64 bits.

> 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
> there.

Only that the printed address will be truncated, but yes,
nothing disastrous.

>
>  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
patching?

--- 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
   *-*-mingw*)
     gcc_cflags_optlist="$gcc_cflags_optlist nocygwin"
     gcc_cflags_nocygwin="-mno-cygwin"
+    limb_64=longlong
+    path_64=""
+    # silence many pedantic warnings for w64:
+    gcc_64_cflags="$gcc_64_cflags -std=gnu99"
     ;;
 esac


>
> --
> Torbjörn
>

Thanks.

--
Ozkan