Re: [Pyode-user] Problems with PyODE on Windows

[Ethan Glasser-C. <gl...@cs...>]

Simon McGregor wrote:
> This fix works!
> 
> Well, on a single-precision build anyway. I tried the double-precision
> build with the following changes to setup.py:
> 
>    LIB_DIRS += [os.path.join(ODE_BASE, "lib", "ReleaseDoubleLib")] #
> VS annoyingly builds to ReleaseDoubleLib
>    LIBS     += ["ode_double", "user32"]  # VS annoyingly builds
> ode.lib as ode_double.lib
>    CC_ARGS  += ["/ML /DdDOUBLE"] # VS annoyingly uses /D where gcc uses -D

OK, I only have one idea here, which is to try:

["/ML", "/DdDOUBLE"]

instead of

["/ML /DdDOUBLE"]

I make this suggestion solely on the fact that the CC_ARGS (not
CC_FLAGS, sorry :)) call has .split() at the end.

>> I spoke to Matthias Baas, who writes:
>>
>> "I was actually thinking it might be a good idea to write a new version
>> that's entirely based on ctypes instead of Pyrex, but there were just
>> too many other things that kept me busy and PyODE just is a rather
>> low-priority for me at the moment."
> 
> Is that a good idea? I'm new to both ctypes and Pyrex, so I don't know
> the ins and outs of both. After a quick perusal of ctypes, I can't see
> how to interrogate a linked library's export table (which I'd quite
> like to be able to do!)...

It would at least obviate the need for figuring out how to compile
things. I agree that I can't see a way to look at the symbols that are
exported, but there has to be some way, because it's capable of figuring
out that "dInitODE" is an existing symbol, and "foo" isn't. Anyhow, I
don't see this as a major hurdle; whoever undertook this task would be
working from the ODE docs and defining wrappers (much like the pyrex
code already does).

Ethan