Syntax failure when building PyNormaliz wheels under Windows

[w-bruns]

@mkoeppe

See Normaliz/PyNormaliz#120 for the failure. As far as I can say, the problem is that slong expands to long long int and there is no suitable definition for that case. Under Linux 64 and MacOs long long and long are semantically equivalent, but not under MS Windows 64.

We have seen a similar problem before in the incompatibility of Flint 3.3.1 and e-antic 2.1.0.

I do not completely understand the mechanics of slong. Where is it defined? In Flint? I am positively surprised that I could compile Normaliz (including e-antic) uner MSYS/MinGW64.

[videlec]

The slong indeed comes from flint. It is a typedef defined in src/flint.h.in that gets transformed into flint.h during the build.

I do not think that flint claims to support MS Windows 64.

[w-bruns]

I have checked flint.h both in Linux64 and Windows via MingW64. flint.h changes significantly from version 3.0.1 to 3.3.1. Independently of the operation system we have

typedef long long int slong in Flint 3.3.1
#define slong mp_limb_signed_t in Flint 3.0.1

There is no prpoblem in Flint I think, but e-antic does not seem to provide the definitions that are necessary for the expansion of slong to long long int. I guess that uncer Linux64 or MacOs is that both long and long long are 64 bit.

[videlec]

Do you mean that the following two expands differently depending on the system?

#include <e-antic.h>
slong a;

and

#include <flint.h>
slong a;

It seems weird to me, as the type slong is not redefined in e-antic.

[w-bruns]

I am not sure that it is a good idea to redefine it. I would not try it, and I don't think that would solve the problem. I see two ways out:

1. mkoeppe tries to use Flint 3.0.1. For sure good enough for e-antic.
2. Update of e-antic in which functions involving slong have a definition that allow the expansion of slong to long long int.

A similar problem could arise for Flint's ulong.

[mkoeppe]

Downgrading FLINT is not an attractive option, obviously

[w-bruns]

For sure it is not. The alternative is upgrading e-antic.

For the release 3.11.0 of Normaliz I had no choice for the Windows binary.

[w-bruns]

It took me a while to really understand the syntax failure, even if it eventually boils down to the fact that long and long long cannot be identified under MS Windows. But this dangerous identification should not be necessary at all.

In renf_elem_class.cpp:1389 the template Integer of ternop_primitive is explicitly set to long, whereas it is set tolong long via the slong that we get from the expansion of renf_elem_addmul_si (defined in renf_elem.h:247).

[w-bruns]

I am very interested in getting the syntax failure fixed. Could the following work ?

renf_elem_class& renf_elem_class::iaddmul(const renf_elem_class& a, long b)
{
    long long bll = b;
    return ternop_primitive<long long, renf_elem_addmul_si>(*this, a, bll);
}

Perhaps not a long term solution, but worth trying. The same for renf_elem_class::isubmul.