25th anniversary Makefiles don't build

[SamVanheer]

Trying to build the 25th anniversary versions of the Makefiles fails due to a couple of problems:

• The GCC version is hard-coded to 4.6 located at /valve/bin/gcc-4.6. This was the case before as well, but this means you'd need to modify the Makefile to get it to build at all. Installing such an old version isn't trivial since it's no longer provided by package managers by default
• Perforce integration seems to be enabled by default causing builds to fail when the p4 command is executed
• When Perforce integration is disabled the P4_EDIT_START command tries to chmod a file that won't exist yet the first time you build it
• Makefile.hl_cdll references a non-existent file called common/validator.cpp (line 117). Is this file missing or should it be removed from the Makefile?
• Makefile.hl_cdll fails to link with SDL2: /usr/bin/ld: cannot find -lSDL2: No such file or directory. This is because the symlink is broken. This is probably also the case for the .dylib symlink so both should be checked and fixed. Re-creating the symlink seems to work fine. If the files were touched on Windows and then committed then that could be why they broke.

This was tested with a freshly cloned copy of the latest commit in Ubuntu 22.04 64 bit.

[JoelTroch]

Makefile.hl_cdll references a non-existent file called common/validator.cpp (line 117). Is this file missing or should it be removed from the Makefile?

Worth mentioning this file is not present on Visual Studio projects (both VS2010 and VS2019).

[SmileyAG]

common/validator.cpp has been used to build the client module since at least from the steam_legacy version of Half-Life, so this file was clearly forgotten to be included in the HLSDK.

But at first glance it looks like it contains nothing but the placeholder function (void ValidatorStub()) and the pointer to it (pfnValidatorStub). Of course, it is always possible that its logic can only be compiled for binaries from platforms like _WIN32, but I doubt that this is the case here. No references from other functions to it as well.

Here is the version of the compiler that is listed in the .comment section from the official binaries of latest version of Half-Life:

String dump of section '.comment':
  [     0]  GCC: (SteamRT 5.4.0-7.really.6+steamrt1.2+srt2) 5.4.1 20160803

[SamVanheer]

The first two problems should be fixed when following the instructions added to the readme:

Linux binaries are built using Makefiles found in the linux folder, and are expected to be built / run in the Steam Runtime "scout" environment. You will need to set the environment variables VALVE_NO_AUTO_P4=1 and USE_STEAM_RUNTIME=1 while building.

Though i question why the Makefile doesn't default to the correct behavior. This is probably because the files were taken directly from the internal versions but for mods this will cause problems.

[shawns-valve]

I tried to clean some of this up, though my Linux knowledge is limited, so I may have missed some things.

FWIW, if anyone in the community has improved makefiles and wants to submit a pull request, I'll take a look at it; the current files were really made for our internal build environment and just slightly tweaked to get them working for the SDK.

[APGRoboCop]

I've used Linux Makefiles for over 12 years, even though I also had to learn to use CMake as well as AlliedMod's AMBuild.

[SamVanheer]

I built the SDK with the latest changes and it's pretty straightforward now, though i suspect beginners will get tripped up on the chmod error messages with CREATE_OUTPUT_DIRS=1 because it looks like something went wrong when it still works as intended.

Building in a container isn't the easiest thing to do when you've never done anything like that before, but simply removing the version number from the compiler name uses the currently installed version which is enough to build it without a container.

People will probably use community-maintained SDKs even now so i doubt it will come up often.

I'll also point out that people have tried to use community-created updated dlls as replacements for the original game dlls which can get them VAC banned. Using the original game directory names in the output paths might give people the idea that this is something they can do. While it doesn't look like VAC is actually banning people for this right now i'm concerned it might change later on and get them banned.

I implemented a check in halflife-updated that shuts the game down when the dlls are used to replace any of Valve's game dlls, but that can easily be disabled by changing the source code.

I don't know if this is an issue that needs addressing here but i'll mention it just in case.

[APGRoboCop]

Well...I've not been using the HLSDK 25th Anniv apart for RCBot, but I think using those headers seems pointless. Also, I do get worried or concerned if I recompiled the cl_dlls for DMQ2 with HLSDK 25th if it will trigger VAC ban false positives... But with the new DMQ2 as well as the DMC Pro versions recompiled for the server /dlls seems fine. And I've had no reports of VAC bans so far.

https://apg-clan.org/vbdownloads.php?do=download&downloadid=1331

I also did the same for VadaVaka's Ricochet Community Patch, but didn't use HLSDK 25th.

[0Ky]

@SamVanheer The issue of players replacing the original game's client dll is already being tracked in issue #1210.

Unfortunately, I don't think VAC flags modification or replacement of the game's client dll for Half-Life. I've contacted Valve support not long ago regarding this issue and they were unable to confirm or deny for obvious reasons related to protecting the integrity of their anti-cheat system. Although, with certainty I can say that players have been exploiting this for well over a decade or two without any reports of VAC bans. They either use outdated versions of the game's client dll to exploit bugs patched in newer versions or use open-source projects like BugfixedHL, BugfixedHL-Rebased, Adrenaline Gamer and OpenAG to enhance the gameplay and provide features not capable with the original game client, such as automated bunny-hopping, perfect frame duck tapping, reintroducing patched bugs like _special, force-replacing player models in-game and programming custom automations directly into the official game by replacing its client dll rather than using it as a mod.

[tschumann]

I've pushed #3848 as a fix - looks like after #3807 it was fine, it just needed gcc to be called gcc/g++. Tested with gcc 9.4.0