Windows build failure in VS

[HansCox]

I've tried building ESP in Visual Studio Community 2015 twice, restarting with fresh git clones, and I get this error, which I haven't been able to fix:

2>c:\users\hans cox\documents\esp-github\esp\xcode\esp\src\istream.h(14): fatal error C1083: Cannot open include file: 'ofxOsc.h': No such file or directory (compiling source file src\iostream.cpp)

My build fails (1 succeeds, 1 fails). I've tried adding the source files for ofxOsc in the Solution Explorer, but I am told they cannot be opened, in errors that follow when I try to build. I'm on a 64-bit Windows 10 machine. I'd really like to use ESP for my thesis work, please help!

[nebgnahz]

@Wooster1 I believe the issue is that VS project didn't have the right include path (see [1]). The OSC stream is just added recently and we haven't tested it fully on Windows (apologies!)

I don't have a Windows machine at hand so I cannot test this right now. But configuring the include directory in the project settings should work.

Alternatively, if your thesis doesn't need to use OSC input data, you can simply comment relevant code out in istream.h and istream.cpp`.

[1] https://github.com/damellis/ESP/blob/master/Xcode/ESP/ESP.vcxproj#L161

edit: to make it fully work, you might also need to add OSC implementation files. I see a couple of ClCompile tags that are for other OpenFrameworks plugin libraries.

[2] https://github.com/damellis/ESP/blob/master/Xcode/ESP/ESP.vcxproj#L183

[nebgnahz]

For reference: 32fca593c029a4637ae3dfb545689adc3915d717 is the change that adds OSC support. Assume ${ADDONS_PATH} is the path for OpenFrameworks add-ons.

Additional include path:

${ADDONS_PATH}/ofxOsc/src
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/osc
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/ip

OSC source file paths:

${ADDONS_PATH}/ofxOsc/src/ofxOscBundle.cpp
${ADDONS_PATH}/ofxOsc/src/ofxOscMessage.cpp
${ADDONS_PATH}/ofxOsc/src/ofxOscParameterSync.cpp
${ADDONS_PATH}/ofxOsc/src/ofxOscReceiver.cpp
${ADDONS_PATH}/ofxOsc/src/ofxOscSender.cpp
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/ip/IpEndpointName.cpp
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/ip/posix/NetworkingUtils.cpp
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/ip/posix/UdpSocket.cpp
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/osc/OscOutboundPacketStream.cpp
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/osc/OscPrintReceivedElements.cpp
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/osc/OscReceivedElements.cpp
${ADDONS_PATH}/ofxOsc/libs/oscpack/src/osc/OscTypes.cpp

[HansCox]

Thanks @nebgnahz , that did fix the osc error. Now I'm having trouble with finding GRT/GRT.h:

Error C1083 Cannot open include file: 'GRT/GRT.h': No such file or directory (compiling source file src\istream.cpp) ESP c:\users\hans cox\documents\esp-github\esp\xcode\esp\src\istream.h 11

I've tried moving the compiled GRT (renamed from grt-debug.lib to grt.lib) in the directory tree, but that didn't fix it. I see an issue with building on Linux, related to not finding GRT/GRT.h, but I don't know how to connect the solution there to this problem I'm having.

[nebgnahz]

Great to hear that the OSC is fixed.

For GRT/GRT.h not found, issue #196 GRT/GRT.h file not found is more specific to Mac OS. At that time, GRT has to be installed on the system; hence the solution I suggested, brew install. We later decided not to depend on the installed header. So the build configuration (Xcode for Mac OS, CMake for Linux and VS for Windows) are looking for headers in third-party/grt.

For Windows and VS projects, this line is supposed to do the trick.

I am also surprised to find out that this <IncludePath> tag does not exist in Debug|x64 group. To make it work, you need to configure the include path (or the AdditionalIncludeDirectories as you did for solving the OSC problem).

Apologies that we are mostly doing development on Mac OS and test the deployment on Linux; Windows is supported but not as well maintained as other platforms (also we don't have a Windows at hand to test/fix promptly...)

P.S. The problem you have now is at the compilation stage. It doesn't need any compiled library; it needs to be able to find all the source .h header files. The library grt.lib is only needed at the stage of linking. If missing the library, you will see undefined reference to XXX error instead of Cannot open include file XXX. Hope this is clear and helpful.

[HansCox]

Thanks so much for your help, @nebgnahz . That did fix the GRT problem. Now I'm seeing 280 errors about syntax etc, in ws2def.h, winsock2.h, ws2ipdef.h, and ofxTCPManager.h.

Error C2011 'sockaddr': 'struct' type redefinition (compiling source file src\istream.cpp) ESP C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2def.h 221

Error C2059 syntax error: 'constant' (compiling source file src\istream.cpp) ESP C:\Program Files (x86)\Windows Kits\8.1\Include\shared\ws2def.h 421

[nebgnahz]

This is a Windows issue. I've seen this error before, and it has happened to many other people Stackoverflow discussion.

I've fixed it for output stream (see commit 330da636ddaaf2f41efb4f7f7400c818f33358ec) but TCP input stream is added recently (commit 319011486ec32fef34d0212bce1560073daca4bf 13 days ago).

The proposed fix I have is to add the following line to the start of istream.h which defines the macros properly and include header files in the proper order. I cannot test this myself right now.

#ifdef TARGET_WIN32
#define _WINSOCKAPI_
#define WIN32_LEAN_AND_MEAN
#include <WinSock2.h>
#include <WS2tcpip.h>
#include <Windows.h>
#endif

P.S. If you actually don't need many of the recently-added features (such as OSC/TCP streams), one thing you can do is to checkout a previous version that's guaranteed to work. We held a workshop on 2016-08-12 and the release should be good to go.

P.S.2 If you have actually fixed all of these, pull requests are welcome.

[nebgnahz]

@Wooster1 I finally got the chance to use a Windows machine to debug this issue. I've created a PR #380. You can test it with the windows-build-fix branch.

[HansCox]

I won't get the chance to try it for a few days, and thank you very much for taking the trouble to do that, to try it on a Windows machine. You could have kept it just for Mac and Linux, but you are making it available for Windows as well, and I appreciate it.

[damellis]

BTW, you may have to copy over third-party/ofxGrt to third-party/openFrameworks/addons again. It's been updated recently.

[searndt]

Hi, I experience the same problem as mentioned above. I get the error that it cannot open the GRT.h file. I looked at the code and at 'the line that does the trick', but in my project that line was already inserted. When I am looking at the folder this line is directing to (..\third-party\grt), this folder is completely empty. Is there supposed to be any file in here? I would very much appreciate your help.

[nebgnahz]

@searndt, yes, the directory ..\third-party\grt is supposed to hold the source code for GRT. Please check the program you used to clone the repository and make sure all its submodules are recursively cloned as well.

More: We manage GRT as a dependency using git submodule. On *nix machine, the setup.sh script is responsible for initializing and updating the submodules. On Windows machine, we typically do it with some GUI-based git client. There may need additional configuration telling the git client to clone everything. For reference, here is a list of all the files in my third-party folder (only showing with a depth of 2).