[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] fmodf on msvc transform.c... any ideas brian?



Hi René,

René Dudfield wrote:
ah, nice one.

I think Lenard made some fixes not long ago to the pixel array stuff,
maybe that has something to do with it.

I chased down one memory access violation in pixelarray.c. A patch should be commited shortly. The other patch simply removes a memory leak.

I tied uninstalling Numeric and running the tests, and didn't have any
crashes -- on linux.  So I'm not sure what it is.  Maybe the pygame
directory needs deleting because there's a conflict perhaps?

Nicholas tried compiling and testing on windows with mingw gcc and it
seems to work for him too.

After the change to draw_test.py (SVN 1412) and my memory leak patch (SVN 1409) everything passes for me, though the memory access hasn't been dealt with yet.


On Sat, Jun 28, 2008 at 3:38 PM, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:
fmod works fine with msvc. I don't know why fmodf doesn't. Know it's back to
crashing in some unit test in _numericsurfarray.pyd, possibly because it
doesn't run the tests with numeric installed...

On Fri, Jun 27, 2008 at 6:35 PM, René Dudfield <renesd@xxxxxxxxx> wrote:
hey,

it looks like fmodf doesn't compile with msvc.  I tried using fmod
instead, so hopefully that works.  I thought fmodf was quite portable,
but seems maybe it's not.

Maybe it needs the math library linked in or something?
http://thorbrian.com/pygame/builds.php


As for the fmodf problem it is a mystery. For MinGW fmodf is a statically linked function defined in an MinGW specific library. For Visual C++ Toolkit 2003 fmodf is just an inline function, defined in math.h, that calls fmod. The only way this should fail is if Brian's build machine has an itanium processor or something, in which case fmodf would be declared as an external function.

--
Lenard Lindstrom
<len-l@xxxxxxxxx>