reference to 'byte' is ambiguous when compiling example using msys2

[cyberboy666]

im trying to port my linux openframeworks program to windows by following the msys2 instructions.

i managed to get openframeworks examples compiled and running, however when i now try to compile an example in ofxNDI i get a whole bunch of errors surrounding:

C:/msys64/mingw64/include/rpcndr.h:64:11: error: reference to 'byte' is ambiguous

i found this issue which seems similar but couldnt see anywhere in the ofxNDI code where that fix could apply.. or any definition of or use of byte at all in there... im guessing its conflicting headers or something ?

any ideas for this or do i just need to use visual studio on windows ?

more of the errors in stacktrace

``` In file included from C:/msys64/mingw64/include/objbase.h:8, from C:/msys64/mingw64/include/shlwapi.h:14, from C:/msys64/home/Gabriela/of_v0.12.0_msys2_mingw64_release/addons/ofxNDI/src/ofxNDIdynloader.h:20: C:/msys64/mingw64/include/rpcndr.h:64:11: error: reference to 'byte' is ambiguous 64 | typedef byte cs_byte; | ^~~~ In file included from C:/msys64/mingw64/include/c++/13.2.0/bits/memory_resource.h:38, from C:/msys64/mingw64/include/c++/13.2.0/string:58, from C:/msys64/home/Gabriela/of_v0.12.0_msys2_mingw64_release/libs/openFrameworks/utils/ofConstants.h:13, from C:/msys64/home/Gabriela/of_v0.12.0_msys2_mingw64_release/libs/openFrameworks/ofMain.h:6, from C:/msys64/home/Gabriela/of_v0.12.0_msys2_mingw64_release/addons/ofxNDI/example-receiver/src/main.cpp:1: C:/msys64/mingw64/include/c++/13.2.0/cstddef:69:14: note: candidates are: 'enum class std::byte' 69 | enum class byte : unsigned char {}; | ^~~~ C:/msys64/mingw64/include/rpcndr.h:63:25: note: 'typedef unsigned char byte' 63 | typedef unsigned char byte; | ^~~~ C:/msys64/mingw64/include/rpcndr.h:397:170: error: reference to 'byte' is ambiguous 397 | typedef void (__RPC_API *CS_TYPE_TO_NETCS_ROUTINE)(RPC_BINDING_HANDLE hBinding,unsigned __LONG32 ulNetworkCodeSet,void *pLocalData,unsigned __LONG32 ulLocalDataLength,byte *pNetwor kData,unsigned __LONG32 *pulNetworkDataLength,error_status_t *pStatus); ```

[leadedge]

Unfortunately I can't test this because the MingW additions are contributed by others. Perhaps they may offer suggestions here.

I note an addition in "ofxNDIdynloader.h" - #include <cstddef> // to avoid NULL definition problem

A brief look here shows that it contains a "byte" type. Try excluding that header.

[cyberboy666]

hello @leadedge - thanks for the suggestion. unfortunately commenting out that line did not help.

i decided to try using visual studio 2019 while running of_v0.12.0_vs_release.zip as suggested in this guide.

other examples are running fine, however unfortunately when i try running example-receiver i get the same errors.

any ideas on how to get this addon working on windows in general ?

[leadedge]

I set up Openframeworks 12 and Visual Studio 2019 and can compile successfully as long as I use C++ Language standard "Default (ISO C++14 Standard)". If I change to C++17 or C++20 there are all sorts of errors building the Openframeworks library. A quick search indicates that the language standard is related to the 'byte' ambiguous symbol problem.

There are some redundant includes in ofxNDIsender.h but removing these does not prevent the errors.

What language standard are you using? Set this to C++14 for all configurations and platforms and see if this makes a difference.

[cyberboy666]

ok that must be the difference - i checked and it was set to using C++17 for my build.

unfortunately when i set it to C++14 as you suggest, a bunch of other errors appear that look like they come from base openframeworks files where atleast C++17 is expected - i can see that:

• ofSingleton.hpp
• ofRandomEngine.h
• ofRandomDistributions.h

are affected.

im a bit confused how it compiles for you with C++14 if you are also running of0.12 like i am. (also confused why c++17 does not compile for you but it does for me)

in the of0.12 changelog it does say:

all: C++17 default

but not that c++14 support is being dropped... so hmmm would be nice to have this addon compiling for C++17 too.. i can try some more to see how to make it work (although a bit out of my depths)

and in meantime i might try it again with of0.11.2 and see if that is happy compiling C++14

[leadedge]

Sorry my mistake. I was using of 11.2 and not 12.0. For all the current projects I am using of 11.0 and Visual Studio 2022.

I tried again and now I can't even build for C++14. It's complaining about filesystem - error C2027: use of undefined type 'std::filesystem::path' error C2386: 'filesystem': a symbol with this name already exists in the current scope error C2079: 'ofDirectory::myDir' uses undefined class 'std::filesystem::path'

I think I risk getting into an unrecoverable state. What I will do is set up Openframeworks 12.0 from new on a different computer for Visual Studio 2022, which is what I am using for all the projects, and see if it builds for C++17.

[leadedge]

I set up of of 12.0 and I think I found the problem. Unfortunately it's not simple but I think there is a way to make ofxNDI work.

Using C++17 breaks the build if you include "shlwapi.h". All is OK if \it's not included. This is used in ofxNDIdynloader to find the executable path and I think I can use some string functions to replace that.

But, more seriously, it also breaks if you include "dx11.h", so all the Spout Openframeworks examples fail for C++17.

The only thing I can do is document this and Openframeworks 11.2 is as far as it goes because dx11.h is definitely required.

It's a failure on the Microsoft side. After some searching, I tried the suggested workarounds but they don't work.

[cyberboy666]

thanks a lot for the update!

thats a pain that it breaks so much.

fwiw i got it all working for me using of11.2 and visual studio 2019

tried again on msys2 with c++14 but hit against another error regarding shlwapi.h

(undefined reference to '__imp_PathRemoveFileSpecA',) decided not to sink any more time on this since the visual studio approach is working anyway..

[leadedge]

If you get the same error with msys2, it confirms that this is a Microsoft problem.

I am certain that I can bypass shlwapi.dll. I will look at it tomorrow. You are right, these things can consume much more time than they are worth and as soon as there is a solution, that's the only path you can take.

[leadedge]

Update.

I removed dependence on shlwapi in the addon and the modified files are uploaded to the Master branch. All works well as far as I can tell. I also made modifications to the Spout SDK files but d3d11.h still caused the error when used with Openframeworks.

However, I think I have found the root cause of the problem. Remove "using namespace std" from ofMain.h. The library still builds and d3d11.h no longer conflicts. I don't know exactly why but it enables use of Openframeworks 12 with the Spout SDK.

[leadedge]

FYI

It turns out that Microsoft acknowledge the problem. Look for "_HAS_STD_BYTE" on this page.

With Visual Studio it can be solved by adding "_HAS_STD_BYTE=0" to the C/C++ Preprocessor Definitons.

I think you can just use "#define _HAS_STD_BYTE 0" in the source code before including anything, but I have not confirmed this.