search

robotconscience / ofxLibwebsockets

[Deprecated] openFrameworks wrapper of libwebsockets for WebSocket client and server functionality
Other
171 stars 68 forks source link

Win32 won't link and/or run on 0.9.0 branch #64

Closed mattfelsen closed 9 years ago

mattfelsen commented 9 years ago

Ran into this while playing with my new changes. If I use the commandLine pg to make a project, make sure the libs for Win32 match how they were in addon_config.mk (i.e. websockets.lib and zlib_internal.lib), and add the preprocessor definition, I get unresolved symbols when trying to compile. If I add websockets_shared.lib, specifically before websockets.lib rather than after, it will compile but complain about not finding websockets_shared.dll when launching. I assume this was working for you before when you originally created the libs in b05d7d9545c64e46fd436577175da4020759e393?

robotconscience commented 9 years ago

What unresolved symbols? Also, does it seem like you still need to define the _WIN32_WINNT? That was going to be my suggestion, but seeing that OF took out its defines of it.

I think you don't want the "shared" one. Maybe the libs path is being weird?

mattfelsen commented 9 years ago

Not sure on the preprocessor def, but I'm seeing the same thing with & without it. The lib paths look good & it's finding the x64 libs fine.

The unresolved symbols don't actually look LWS related, more like VS stuff: unresolved external symbol impvsnprintf referenced in function __lws_log unresolved external symbol imp__iob_func referenced in function _lwsl_emit_stderr

If the websockets_shared.lib & .exp aren't needed, can we remove them from the repo to avoid confusion? I can pull them out in my PR.

robotconscience commented 9 years ago

Woah, weird. Googling around, those should be included from <wtypes.h>, a windows include. With those things, it's sometimes a conflicting define somewhere...

Let me know how that looks, can dig into it myself a little later. Try that preprocessor def, see if that works/helps! (the 501, not 500)

mattfelsen commented 9 years ago

I think part of your post got formatted out...which file were you talking about including?

robotconscience commented 9 years ago

Oh weird, just fixed it. It's not included explicitly anyways, one of those nice cascading system includes (probably from winsock2.h or windows.h). You should have to include it... It also could be an issue with which headers we are or aren't including from libwebsockets. I think the logger is new from the last version we were working with, for example.

mattfelsen commented 9 years ago

I just tried the libs from @armadillu's fork - they work fine, no #include <wtypes.h>, no preprocessor definitions. Would you be opposed to just included his updated binaries, assuming they were compiled with OpenSSL?

mattfelsen commented 9 years ago

Meant to mention that wtypes.h didn't help -- actually started getting tons of errors about redefintions/conflicts, with both the 501 and 500 preprocessor defs and without it.

robotconscience commented 9 years ago

Yeah of course! I haven't been working on Windows in a bit, trust that you homies know what you're doing :)

Just make sure it works with the PG folder structure. Thanks for leading the charge on this, dude!

armadillu commented 9 years ago

Matt, are u seeing crashes on win? There definitely are some race condition issues on the thread creation destruction; What's on my my for works for OS X and Win for me (mostly), but I'm pretty sure this is very HW dependent. Also, still getting some crashes (around 5%) of the time when closing sockets on win

mattfelsen commented 9 years ago

Yikes, ok. I'll do some testing with the examples before committing your binaries. Did you compile in openssl, by the way?

robotconscience commented 9 years ago

@armadillu You think that's in lws or in my code? It's been really stable on OS X, but I haven't used it as extensively on Windows.

armadillu commented 9 years ago

I would say it's the addon code; but hard to tell 100%. I think thread spawn times are very different on windows and OSX; and they also change a lot across different hardware.

This (https://github.com/armadillu/ofxLibwebsockets/commit/3d7341a005dfcdedf5c28c209add99601d0824aa) made connections work for me on a MS Surface tablet; without it connections just never happened.

They would only happen when I set ofSetLogLevel(OF_LOG_VERBOSE)... That's what lead me to add some random sleeps in there to make it work; but it's obviously a dodgy patch. Will have a deeper look when I have some free time; I just needed it to work for a client demo at the time.

armadillu commented 9 years ago

@mattfelsen I can't remember; It was fairly easy with c+make... I can see if I still have the .vcproj if it helps.

robotconscience commented 9 years ago

Hm, that's super weird! I see what you're thinking, though, with the sleeps. I'll have to dig into the library and see if there's a check we can do to create a lock until we know if the context is made or not.

Looking at their examples, they just go for it: https://github.com/warmcat/libwebsockets/blob/master/test-server/test-client.c

They do a much shorter wait time on the libwebsocket_service call, though... That could be the culprit? https://github.com/labatrockwell/ofxLibwebsockets/blob/de8b21fdc4007b9a7c76dd329b912463dbde2f1f/libs/ofxLibwebsockets/src/Client.cpp#L256

mattfelsen commented 9 years ago

For anyone coming across this, there is a pending PR which addresses this issue https://github.com/labatrockwell/ofxLibwebsockets/pull/63