[CLN-list] MinGW64 build

[Robert Szalai]

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 at 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 at gmail.com>
> > Date: Aug 15, 2012 02:22
> > Subject: Re: [CLN-list] MinGW64 build
> > To: "CLN discussion list" <cln-list at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cebix.net/pipermail/cln-list/attachments/20191028/37ae82fc/attachment.htm>