Add 64-bit support

[kir68k]

Valve today published an update adding Vulkan to the client and 64-bit version of the engine on both the client and servers, providing srcds_run_64 and srcds_linux64.

I've added an envvar and a way to enable/disable it, which works on my machine, but has issues with existing 32-bit libraries:

 failed to dlopen /home/steam/tf-dedicated/bin/replay_srv.so error=/home/steam/tf-dedicated/bin/replay_srv.so: wrong ELF class: ELFCLASS32
Could not load: replay_srv.so
FATAL ERROR: Could not load: replay_srv.so

There is a bin/linux64 and tf/bin/linux64 directory with proper 64-bit libraries including replay_srv.so, but I'm not sure if there's a way of using those other than LD_LIBRARY_PATH.

Making this as a draft until everything is tested and works properly.

[CM2Walki]

I doubt anyone will run the 32-bit version over the new 64-bit version, so you can purge i386. That should solve the issue.

[kir68k]

I doubt anyone will run the 32-bit version over the new 64-bit version

Metamod:Source and SourceMod 1.11 (stable) don't have support for this yet and won't load, so I think most people won't switch to x64 yet.

SM 1.12 (dev) does load when I try, but extensions like DHooks (issue here) are missing, which breaks a lot of TF2 plugins.

I added a check to ensure x64 only gets enabled if using the base image and SRCDS_64BIT=1.
There is no directory check in case someone wants to install SM 1.12 manually and test it.

Without plugins the server starts and works without errors, tested all tags to confirm.

[CM2Walki]

Good point, I forgot about sourcemod and metamod.

Given the architecture problems, it might be warranted to split the dockerfile and setup a multi-platform build. I might be able to do that this weekend.

[kir68k]

I tried to split them with the kir68k@3c135bf commit, although I'm not sure what should be done in bookworm/hooks/build, I added:

docker build --target=bookworm-base -f $(basename ${DOCKERFILE_PATH}) -t $DOCKER_REPO:latest-x64 -t $DOCKER_REPO:base ${BUILD_PATH}.
docker build --target=bookworm-metamod -f $(basename ${DOCKERFILE_PATH}) -t $DOCKER_REPO:metamod-x64 ${BUILD_PATH}.
docker build --target=bookworm-sourcemod -f $(basename ${DOCKERFILE_PATH}) -t $DOCKER_REPO:sourcemod-x64 ${BUILD_PATH}.

Which is what I used to locally build and test the changes. As I understand, the DOCKERFILE_PATH var is controlled by you when using the cloud, right? I assume you'd have to modify that file a bit as the file paths changed, if the new commit's approach works.

The "ci/dockercloud-stage" check currently fails due to the service being unavailable, although if it looks for /bookworm/Dockerfile it'd fail anyway, since now it's /bookworm/{x32,x64}/Dockerfile.

[CM2Walki]

Which is what I used to locally build and test the changes. As I understand, the DOCKERFILE_PATH var is controlled by you when using the cloud, right? I assume you'd have to modify that file a bit as the file paths changed, if the new commit's approach works.

Yes, that variable is controlled via docker hub. However, it's quiet silly, it just needs to find a valid Dockerfile and then it just runs what's in build/hooks. I made the necessary adjustments and now the tests are passing.

[CM2Walki]

I'll merge the PR and then the new tags should be available.

Thanks for the contribution!