Error Compiling SoundSource when X11 is Being Used

[rlwarrior32]

Hello all,

Info:
SFML 2.3.2 (Latest on Ubuntu?)
Dynamically Linked

I'm working on a project that has been successfully using X11. I've recently added Audio, and I started getting compile errors in SoundSource.hpp. I have found if I comment out including X11 and it's code, the error goes away. It appears that both X11 and SoundSource define a Status enum which is conflicting.

Error:

Code: [Select]

/home/derdro/Tools/IDEs/clion-2017.3.1/bin/cmake/bin/cmake --build /home/derdro/Projects/CLionProjects/GBEmu/cmake-build-debug --target GBEmu -- -j 2
[  5%] Building CXX object CMakeFiles/GBEmu.dir/Source/Main.cpp.o
In file included from /home/derdro/Projects/CLionProjects/GBEmu/Source/Main.cpp:4:0:
/usr/include/SFML/Audio/SoundSource.hpp:50:10: error: expected identifier before ‘int’
     enum Status
          ^
In file included from /usr/include/SFML/Audio/Sound.hpp:32:0,
                 from /home/derdro/Projects/CLionProjects/GBEmu/Source/Components/Apu.hpp:14,
                 from /home/derdro/Projects/CLionProjects/GBEmu/Source/Components/Memory.hpp:15,
                 from /home/derdro/Projects/CLionProjects/GBEmu/Source/Gameboy.hpp:12,
                 from /home/derdro/Projects/CLionProjects/GBEmu/Source/Main.cpp:6:
/usr/include/SFML/Audio/SoundSource.hpp:51:5: error: expected unqualified-id before ‘{’ token
     {
     ^
CMakeFiles/GBEmu.dir/build.make:62: recipe for target 'CMakeFiles/GBEmu.dir/Source/Main.cpp.o' failed
make[3]: *** [CMakeFiles/GBEmu.dir/Source/Main.cpp.o] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/GBEmu.dir/all' failed
make[2]: *** [CMakeFiles/GBEmu.dir/all] Error 2
CMakeFiles/Makefile2:79: recipe for target 'CMakeFiles/GBEmu.dir/rule' failed
make[1]: *** [CMakeFiles/GBEmu.dir/rule] Error 2
Makefile:164: recipe for target 'GBEmu' failed
make: *** [GBEmu] Error 2

Any idea the easiest way to fix this? Thanks!

[rlwarrior32]

Potentially related post:

https://en.sfml-dev.org/forums/index.php?topic=2675.msg19011#msg19011

The last poster mentions something like this.

[eXpl0it3r]

Either change header include order or undefine the status X11 macro before using SFML.

Unfortunately there are libraries using global macros with very common names, which then end up clashing with user or other library code.

Windows for example has macros for the names min and max as well as some other short names which I forgot right now.

[rlwarrior32]

Swapping the include order fixed it, thanks a ton!!!!!!