Dear Bruno, thank you for looking into this. I have moved on from CLN and GiNaC on Windows, because I felt it was unmaintained and there was no interest working with me on upstreaming my patch. I hope this time things will work out differently. Bests, Robert On Sun, Oct 27, 2019 at 6:56 PM Bruno Haible <bruno@clisp.org> wrote:
Hi Robert,
On 2018-02-24 you resent your mail and patches from 2012-08-15:
Here is the previous win64 patch set... ---------- Forwarded message ---------- From: "Robert Szalai" <robicjedi@gmail.com> Date: Aug 15, 2012 02:22 Subject: Re: [CLN-list] MinGW64 build To: "CLN discussion list" <cln-list@ginac.de> Cc:
Hi Alexei,
I've splitted the path into 10 parts. There is a bigger one that is
only
s/long/intptr_t/ and s/unsigned long/uintptr_t/ the rest is very small.
Hopefully this can now be applied.
Ditto (the corresponding hunk is not quite optimal, though. {s,u}int32 can be typedef'ed to {,u}int32_t => no need for ugly #if's).
I was thinking of this, however we need exactly the same underlying type as (u)intptr_t for the same sized integer to avoid compiler confusion. So in some cases (e.g. on i686 Linux) stdint.h might define int32_t as int and intptr_t as long and in this case the compiler will complain about multiple definition of the same function.
Bests, Robert
I have applied the 3 parts of your series that were good, and fixed the remaining problems. Indeed, the problems with the overload conflicts (in cl_combine, fprintdecimal, fprinthexadecimal) that are caused by the fact that intptr_t may be 'int', may be 'long', may be 'long long', were hardest to resolve. I chose not to introduce platform-dependent #ifs (too hairy to maintain), nor an autoconf test (because the include files are supposed to be usable by different compilers, and different compilers may define intptr_t differently), but instead use an inline function redirection.
Bruno