Compile error on Linux

[KraXarN]

Hello!
Trying to compile my code on Linux, but it won't work. Same code used on Windows and Mac and both works just fine.
Here are the errors I'm getting:

/usr/include/SFML/Network/Socket.hpp:53:10: error: expected identifier before ‘int’
     enum Status
          ^

/usr/include/SFML/Network/Socket.hpp:54:5: error: expected unqualified-id before ‘{’ token
     {
     ^

/usr/include/SFML/Network/Ftp.hpp:74:14: error: expected identifier before ‘int’
         enum Status
              ^

/usr/include/SFML/Network/Ftp.hpp:75:9: error: expected unqualified-id before ‘{’ token
         {
         ^

/usr/include/SFML/Network/Ftp.hpp:146:41: error: ‘InvalidResponse’ was not declared in this scope
         explicit Response(Status code = InvalidResponse, const std::string& message = "");
                                         ^~~~~~~~~~~~~~~
/usr/include/SFML/Network/IpAddress.hpp:184:28: error: expected unqualified-id before numeric constant
     static const IpAddress None;      ///< Value representing an empty/invalid address
                            ^

/usr/include/SFML/Network/Http.hpp:201:14: error: expected identifier before ‘int’
         enum Status
              ^

/usr/include/SFML/Network/Http.hpp:202:9: error: expected unqualified-id before ‘{’ token
         {
         ^

Thanks!

[Laurent]

As far as I remember, there is some stupid Linux header that has a Done macro. Or Status. None may also be concerned.

Always include SFML last (if possible) and the error should go away. Or #undef the symbol before including SFML headers.

[KraXarN]

Yes, Status was already defined in some X11 header. I fixed it with #undef before the SFML stuff. None and BadRequest was also already defined. After undefining those as well, it compiles and runs just fine!

Thanks for the help, but this might be something that needs to be changed.
It seems to run fine though.

[Laurent]

Thanks for the help, but this might be something that needs to be changed.

I doubt that Xlib headers, as stupid as it is to #define such common symbols, will ever change. And SFML will certainly not try to work around that