[PATCH] support for mingw-w64
sezeroz at gmail.com
Mon Sep 14 12:38:56 CEST 2009
On Sun, Sep 13, 2009 at 4:13 PM, Torbjorn Granlund <tg at gmplib.org> wrote:
> Ozkan Sezer <sezeroz at gmail.com> writes:
> > 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.
> OK, so then that's a good change. (I've fixed it locally.)
One note about it: You are keeping the 0x prefix in your
patch but %p conversion is implementation dependant
and, for example on linux, the 0x prefix is already added.
Try running this:
int main (int argc, char **argv)
printf ("%p\n", (void *) argv);
.. and see for yourself. I suggest removing the 0x prefixes.
> > 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
> I prefer to put it in the X86 part, where we already have a case stmt on
> operating system. (This misses the none-pc-mingw64 case, but we're
> obsoleting the "none" cpu trick for disabling asm. The case stmt you
> used will move up too.)
> I've made that change too, locally.
> My current diff is attached. Please try it.
Your placement of mingw adjustments in configure.in
doesn't work because they are overwritten by the swicth
just below it. The attached one, however works (see
the attached 1.diff which moves the host switch below
the host_cpu switch.)
With that change, I can configure gmp with
and it compiles just fine.
The one glitch is the override failure of localeconv()
in the tests for now, but it can be solved later. So,
this covers the base of it and I would very like to
see this in gmp mainstream.
I am very pleased that you are very helpful with this
and support mingw-w64. Thank you very much.
> We should port the assmebly code, but not by naively copy-and-modify the
> existing code. We should of course use the same source file, and either
> generate Windoze files on a Unix machine, or generate Windoze files as
> part of the Windoze build process.
> (Generating Windoze files on a Unix system might be a good idea if we
> ever want to support M$'s IDE, we then need to generate xml "project"
> files from the Makefiles. I don't think Windoze has the tools to handle
Indeed. Adding w64 asm support would be very nice, but
I am not confident of my very few asm skills. But this must be
the next step, yes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1249 bytes
Desc: not available
More information about the gmp-devel