Author Topic: pysfml-cython (Read 102427 times)

dfanz0r · « **Reply #75 on:** January 31, 2012, 06:49:41 am »

i tried to build the latest version of this, and it fails when trying to build it.

http://pastebin.com/Jeh50YWY

bastien · « **Reply #76 on:** January 31, 2012, 05:32:39 pm »

Are you using the snapshot in the downloads? Sorry, it wasn't up to date. I updated a new one, but currently I'm focusing more on making a “stable” release along with SFML 2. I still need to do some changes in the source, then I'll update the documentation.

dfanz0r · « **Reply #77 on:** January 31, 2012, 10:04:08 pm »

It wasn't the snapshot, i pulled directly from GitHub.

bastien · « **Reply #78 on:** February 01, 2012, 12:45:01 am »

Ah, I see. These two functions are declared as extern in the Cython, and they clash with either their own declaration in sf.cpp, or with those in hack.hpp (but that seems odd).
The problem is that Cython doesn't seem to have any mechanism to make a function not static, but not exported in the DLL either. So I'm just using “extern” and hope that it won't cause too much trouble. On GNU/Linux, I tried to override the linkage with linker args or scripts, with no success.

Could you look for the declaration/definition of wrap_render_states() in sf.cpp and copy them here? Or just copy the whole file.

dfanz0r · « **Reply #79 on:** February 01, 2012, 07:04:04 am »

here i just uploaded the whole file to mediafire
http://www.mediafire.com/?2zk3ivsuvcjnq32

bastien · « **Reply #80 on:** February 01, 2012, 08:46:21 pm »

So it gets declared this way:

Code: [Select]

__PYX_EXTERN_C DL_IMPORT(struct __pyx_obj_2sf_RenderStates) *wrap_render_states_instance(sf::RenderStates *);

It looks like you just need to add DL_IMPORT in hacks.hpp's prototypes.

dfanz0r · « **Reply #81 on:** February 01, 2012, 09:04:50 pm »

and i do that how exactly?

bastien · « **Reply #82 on:** February 01, 2012, 09:47:36 pm »

I have added the changes in the repo. See if it builds now.

dfanz0r · « **Reply #83 on:** February 01, 2012, 09:54:34 pm »

It didnt work, im still getting the same error.

bastien · « **Reply #84 on:** February 01, 2012, 10:07:07 pm »

Can you paste it again? I don't know if the two previous changes didn't do anything or if only replace_error_handler() causes problems now.

dfanz0r · « **Reply #85 on:** February 02, 2012, 12:07:20 am »

here is the output now

http://pastebin.com/yBe2zWtg

bastien · « **Reply #86 on:** February 02, 2012, 12:52:55 am »

I fixed a syntax mistake that I did with the last change, but I don't know if that was the problem.

dfanz0r · « **Reply #87 on:** February 02, 2012, 01:03:50 am »

It builds now but i cant really use it, as it crashes in my own test program and all of the included tests. My test uses your module to create the window and keep track of fps but uses pyOpenGl to render.

here is the build log for the build:
http://pastebin.com/8aRUUjuN

My test creates a window then it just crashes python. The other tests its spits out some errors
this is from lowleveldrawable.py:

Traceback (most recent call last):
File "E:\pysfml2-cython\lowleveldrawable.py", line 7, in <module>
class LowLevelDrawable(sf.Drawable):
AttributeError: 'module' object has no attribute 'Drawable'

Everything works fine in the windows build in the downloads page.

bastien · « **Reply #88 on:** February 02, 2012, 01:10:27 am »

I haven't updated most examples yet, so the last error is normal.
It's difficult for me to guess where the errors exactly come from, as I'm not used to build DLLs on Windows. I know that the Cython developers almost don't use Windows, so this could be a bug in Cython as well.

The thing is, the functions that cause problems shouldn't end up in the DLL in the first place. As far as I know, Cython doesn't allow to make symbols available across compilation units without exporting them in the DLL. At worst, it should be pretty easy to edit sf.cpp manually to remove DL_IMPORT from those functions declarations (but keep the argument of DL_IMPORT(), it should be the return type).

For what it's worth, I didn't have these problems with MinGW when I last built the binding for Windows, and I was already using the same hacks. I was getting crashes at the end of the program with MinGW, however, but I believe the former binding already had that problem.

Currently, I'm focusing on porting all the C++ features (I still need to make Shape inheritance work and port the streaming features), and updating the documentation. I'll try to build the binding on Windows as soon as possible.

dfanz0r · « **Reply #89 on:** February 02, 2012, 01:47:11 am »

Ok, for now i can just use the prebuilt version all im using now is clock window and event. I will need the Audio streaming stuff later on though. Will soon be looking into keyboard and joysticks too. Network would be useful at some point down the road but its not really needed for a while.