Skip to content

Another compiler error #153

@loopyd

Description

@loopyd

Describe the bug
Hey there, realized that I closed my issue too soon. Here's another compiler error. Rather than reiterate my system specs, I'll get straight to the error.

To Reproduce
Compile the project per the documentation with the retail cmake preset. I just used cmake-gui . when in the neo folder.

Expected behavior
The build succeeds, and you have working build output.

Screenshots
This time, here's some more terminal log:

[ 95%] Building CXX object CMakeFiles/DoomBFA.dir/sys/sys_lobby.cpp.o
[ 95%] Building CXX object CMakeFiles/DoomBFA.dir/sys/sys_lobby_backend_direct.cpp.o
In file included from /usr/include/string.h:548,
                 from /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/idlib/sys/sys_includes.h:141,
                 from /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/idlib/precompiled.h:34,
                 from /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/sys/PacketProcessor.cpp:30:
In function ‘void* memcpy(void*, const void*, size_t)’,
    inlined from ‘bool idDataQueue<maxItems, maxBuffer>::Append(int, const byte*, int, const byte*, int) [with int maxItems = 64; int maxBuffer = 8000]’ at /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/idlib/../idlib/DataQueue.h:112:8,
    inlined from ‘void idPacketProcessor::VerifyEmptyReliableQueue(byte, byte)’ at /home/saber7ooth/Documents/repos/Classic-RBDOOM-3-BFG/neo/sys/PacketProcessor.cpp:660:16:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:33: error: argument 2 null where non-null expected [-Werror=nonnull]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
   30 |                                  __glibc_objsize0 (__dest));
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:33: note: in a call to built-in function ‘void* __builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned int)’
cc1plus: all warnings being treated as errors
make[2]: *** [CMakeFiles/DoomBFA.dir/build.make:5690: CMakeFiles/DoomBFA.dir/sys/PacketProcessor.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:174: CMakeFiles/DoomBFA.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
``*

Additional context
Here's my version of GCC:

gcc --version

gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

From research, seems to be a compiler bug. Using precomipled headers has no effect. Code should be modified to work around this bug. I'm not a C++ programmer. The comments around this area of PacketProcessor.cpp:

	// drop some stuff that is potentially dangerous and should not transmit
	idDataQueue< MAX_RELIABLE_QUEUE, MAX_MSG_SIZE > clean;
	RELIABLE_VERBOSE( "rollback send sequence from %d to %d\n", reliableSequenceSend, reliable.ItemSequence( 0 ) );
	for( int i = 0; i < reliable.Num(); i++ )
	{
		byte peek = reliable.ItemData( i )[0];
		if( peek < keepMsgBelowThis )
		{
			RELIABLE_VERBOSE( "keeping %d\n", peek );
			clean.Append( reliable.ItemSequence( i ), reliable.ItemData( i ), reliable.ItemLength( i ) );
		}
		else
		{
			// Replace with fake msg, so we retain itemsequence ordering.
			// If we don't do this, it's possible we remove the last msg, then append a single msg before the next send,
			// and the client may think he already received the msg, since his last reliableSequenceRecv could be greater than our
			// reliableSequenceSend if he already received the group of reliables we are mucking with
			clean.Append( reliable.ItemSequence( i ), &replaceWithThisMsg, 1 );
			RELIABLE_VERBOSE( "dropping %d\n", peek );
		}
	}

Considering the code comments referring to malicious packet protection and my lack of experience with C++, best leave it to the experts.

Also side note, libglew1 and libglew-dev are installed, but not found when generatring, I noticed in the cmake-gui. I'm not sure if this is relevant or not.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions