Can't compile with GCC and G++ 5.11

[gdm413229]

Cloned into my machine, ran ./configure with the cc and cxx set to gcc-5 and g++-5 respectively. The shock is when I typed make and I got a shocking compiler error and the process aborted.

The terminal showed me that one of the source files had an invalid data type for the source behind the dialogue about the minimum amount of DM starts a map requires in a certain context if you want to make deathmatch maps -- you know, shoot everyone else and rack up as many frags as you possibly could.

If anyone can submit a patch or patches to the repository and/or deposit any workarounds, then I don't have this error. Reply to this issue if you have any patches and/or workarounds to this problem if anyone else had the same problems as I did when I attempted to compile this application. GCC 4.9.2 had the same shocking results in the attempt before I told make to use GCC 5.11.

These workarounds you reply to this issue are supposed to make the build process run in harmony without a single process-aborting error.

Feel free to fork this repository if you are dying to fix the build process with standard distros like Ubuntu.

I filed this issue because I am dying to build the source included in this repository without any single error.

Build machine is running Ubuntu 15.04 [kernel 3.19.0-32-generic] and the compilers are GCC and G++ version 5.11

[farhaven]

I'll look into this tonight. Could you paste the actual error message?

[farhaven]

Just to make sure I didn't miss anything, I just rebuilt Yadex on my OpenBSD machine with G++-4.9.3. Works fine.

[gdm413229]

Here's the error message.

src/checks.cc: In function ‘bool IsTextureNameInList(std::__cxx11::string, std::vectorstd::__cxx11::basic_string)’:
src/checks.cc:656:18: error: range-based ‘for’ loops only available with -std=c++11 or -std=gnu++11 [-Werror]
for (string &i: list) {
^
src/checks.cc: In function ‘void CheckTextureNames()’:
src/checks.cc:704:20: error: range-based ‘for’ loops only available with -std=c++11 or -std=gnu++11 [-Werror]
for (SideDef& s: SideDefs) {
^
src/checks.cc: In function ‘bool CheckStartingPos()’:
src/checks.cc:791:80: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
" You need at least %lu", DOOM_MIN_DEATHMATCH_STARTS);
^
src/checks.cc:791:80: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
src/checks.cc:794:80: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
" You need at least %lu", DOOM_MIN_DEATHMATCH_STARTS);
^
src/checks.cc:794:80: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
src/checks.cc:797:84: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
" You need at least %lu", dm, DOOM_MIN_DEATHMATCH_STARTS);
^
src/checks.cc:797:84: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
src/checks.cc:797:84: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
src/checks.cc:797:84: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘size_t {aka unsigned int}’ [-Werror=format=]
src/checks.cc: In function ‘bool IsTextureNameInList(std::__cxx11::string, std::vectorstd::__cxx11::basic_string)’:
src/checks.cc:657:20: error: ‘i’ is used uninitialized in this function [-Werror=uninitialized]
if (! y_strnicmp (name.c_str(), i.c_str(), WAD_TEX_NAME))
^
src/checks.cc: In function ‘void CheckTextureNames()’:
src/checks.cc:706:33: error: ‘s’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!IsTextureNameInList(s.tex1, WTexture )) {

[farhaven]

The first error message ("src/checks.cc:656:18: error: range-based ‘for’ loops only available with -std=c++11 or -std=gnu++11") is extremely interesting because the CXXFLAGS do contain -std=c++11. The line immediately above your first error message should contain the command the compiler was called with. Could you paste that as well? Did you change anything besides setting CC and CXX?

Edit: The other error messages ("format %lu expects...") are because I am developing this on an AMD64 OpenBSD box where a size_t is 64 bits. I'll think about something for Linux users. Probably just skipping warnings for format strings.

[gdm413229]

Tried building with Ubuntu 12.04 with Linux kernel 3.2.0 with the clang++ compiler and it complains about certain functions on libbsd, mainly strlcpy().

The error message is down below

src/cfgfile.cc:918:25: error: use of undeclared identifier 'strlcpy'; did you
mean 'strncpy'?
strlcpy((char *) o->data_ptr, value, 8);
^~~~~~~
strncpy
/usr/include/string.h:131:14: note: 'strncpy' declared here
extern char *strncpy (char *__restrict __dest,
^
src/cfgfile.cc:924:25: error: use of undeclared identifier 'strlcpy'; did you
mean 'strncpy'?
strlcpy (dup, value, strlen(value) + 1);
^~~~~~~
strncpy
/usr/include/string.h:131:14: note: 'strncpy' declared here
extern char *strncpy (char *__restrict __dest,
^
src/cfgfile.cc:933:25: error: use of undeclared identifier 'strlcpy'; did you
mean 'strncpy'?
strlcpy (dup, value, strlen(value) + 1);
^~~~~~~
strncpy
/usr/include/string.h:131:14: note: 'strncpy' declared here
extern char *strncpy (char *__restrict __dest,
^
src/cfgfile.cc:1121:29: error: use of undeclared identifier 'strlcpy'; did you
mean 'strncpy'?
strlcpy((char *) o->data_ptr, argv[0], 8);
^~~~~~~
strncpy
/usr/include/string.h:131:14: note: 'strncpy' declared here
extern char *strncpy (char *__restrict __dest,

Any patches that make those errors a thing of the past are appreciated, so I won't have to run a VM with an instance of BSD just to build YadeX and run it.

[farhaven]

Those errors have been in my "fix these" pipeline for a while. I'll fix them tomorrow.