Nathan Dunfield | 24 Apr 14:22 2012

Re: [Cython] Cython 0.16 issue Windows with Mingw32

On Apr 23, 2012, at 1:28 PM, Stefan Behnel wrote:
> Hmm, that line basically just says "PyCFunction_Call", which is a function
> exported by CPython. I wonder why gcc would consider this "not a constant".
> 
> Could you check if the preprocessor (gcc -E, with all the above includes)
> also sees that on your side?

It turns out I was running a version of MinGW that, while only a few years old, had a quite elderly version of
gcc, namely 3.4 (yes, that's 3.4 and not 4.3).   Once I updated to the most recent MinGW, which has gcc 4.6, and
worked around a known bug in distutils ( http://bugs.python.org/issue12641 ), the issue with
PyCFunction_Call went away and the entire 76k line Cython generated C file compiled without a hitch.  So
probably this is only a problem on very old compilers, and so perhaps not worth investigating further.

	Best,

	Nathan

	

Stefan Behnel | 24 Apr 14:43 2012
Picon

Re: [Cython] Cython 0.16 issue Windows with Mingw32

Nathan Dunfield, 24.04.2012 14:22:
> On Apr 23, 2012, at 1:28 PM, Stefan Behnel wrote:
>> Hmm, that line basically just says "PyCFunction_Call", which is a
>> function exported by CPython. I wonder why gcc would consider this
>> "not a constant".
>> 
>> Could you check if the preprocessor (gcc -E, with all the above
>> includes) also sees that on your side?
> 
> It turns out I was running a version of MinGW that, while only a few
> years old, had a quite elderly version of gcc, namely 3.4 (yes, that's
> 3.4 and not 4.3).   Once I updated to the most recent MinGW, which has
> gcc 4.6, and worked around a known bug in distutils (
> http://bugs.python.org/issue12641 ), the issue with PyCFunction_Call
> went away and the entire 76k line Cython generated C file compiled
> without a hitch.  So probably this is only a problem on very old
> compilers, and so perhaps not worth investigating further.

Thanks for reporting this back. Given that this is "only" MinGW, which
requires some work on user side anyway to get it properly installed and
used by Python builds, I agree that we can expect those who use it to also
be able to install a somewhat recent version if they run into this.

After all, gcc4.x is very likely to produce faster code for recent
processors than gcc 3.4, so upgrading is a way better alternative than just
"making it work" on our side.

Stefan

Gmane