TF2 Linux crash after sdk update

[waldotf]

After the 9/16 update (https://github.com/alliedmodders/hl2sdk/commits/tf2), some SP functions segfault (notably, anything which sets entity keyvals).

Additionally, some engine functions have been added/removed, as in (#411).

Side note, I and others tried to build with these changes, but the Linux build scripts did not behave well. After a few modifications to get around those issues (https://github.com/JoinedSenses/Source.Python/tree/update_tf2_sdk_2), still ran into issues loading the plugin e.g.

[Source.Python] Loading...
=========================================================================
[SP-LOADER] Could not load library: bin/core.so
[SP-LOADER] Error Reported: /srv/srcds/tf/addons/source-python/bin/core.so: undefined symbol: _ZTI11CBaseEntity
=========================================================================
Failed to load plugin "addons/source-python"

Both server and build on Debian 9.

Guidance with build and/or updated/patched binaries would be very helpful.

[Ayuto]

You shouldn't change the order of the includes. This is likely causing the undefined symbol.

The segfaults are caused by the new vtable of some of the SDK classes. Unfortunately, I'm currently not at home, so I can't trigger a new build. But I will travel back today, so you can expect a new build tomorrow.

[CookStar]

Just apply #411 and recompile and you will be good to go.

[waldotf]

From a clean copy of the repo with #411, I get this error when I run ./Build.sh tf2:

In file included from /usr/include/c++/6/complex:45:0,
                 from /root/sp/Source.Python/src/thirdparty/boost/boost/detail/container_fwd.hpp:98,
                 from /root/sp/Source.Python/src/thirdparty/boost/boost/functional/hash/extensions.hpp:22,
                 from /root/sp/Source.Python/src/thirdparty/boost/boost/functional/hash/hash.hpp:572,
                 from /root/sp/Source.Python/src/thirdparty/boost/boost/functional/hash.hpp:6,
                 from /root/sp/Source.Python/src/thirdparty/boost/boost/unordered/unordered_map.hpp:18,
                 from /root/sp/Source.Python/src/thirdparty/boost/boost/unordered_map.hpp:17,
                 from /root/sp/Source.Python/src/core/modules/commands/commands_client.cpp:33:
/usr/include/c++/6/sstream:300:7: error: ‘struct std::__cxx11::basic_stringbuf<_CharT, _Traits, _Alloc>::__xfer_bufptrs’ redeclared with different access
       struct __xfer_bufptrs
       ^~~~~~

which I attributed to the #define private public in core/modules/commands/commands_client.cpp:31.

Thanks for the quick response, I really appreciate it.

[Ayuto]

This might be caused by the GCC version. Every version behaves slightly differently. We use an older server with an older GCC version 4.8 oder 5.x to make sure older servers don't have any problems with the GLIBC requirements.

[JoinedSenses]

why put all includes after the #define private public hack? that is the cause of the above problem, when it seems that define is only there for a convar member

[JoinedSenses]

access modifier should not be modified elsewhere. multiple files do this - commands_client.cpp is not only file guily of this.

[CookStar]

Fixing Undefined Behavior has to be done this way. CookStar@635341c

However, that is not the only problem with the new g++ version, SP does not work even with this fix.

[JoinedSenses]

Fixing Undefined Behavior has to be done this way. CookStar@635341c

However, that is not the only problem with the new g++ version, SP does not work even with this fix.

Have you tried including #411 with that edit ?

[CookStar]

It's not just TF2, it doesn't work in any game.

I also think that we should be able to compile "Source.Python" with the new g++/MSVC, but we have to start by identifying the cause.

[jordanbriere]

I also think that we should be able to compile "Source.Python" with the new g++/MSVC, but we have to start by identifying the cause.

You will likely always face issues no matter what unless you recompile all dependencies (especially the SDKs themselves).

[CookStar]

SourceMod seems to compile with the newer version of g++ (currently clang), so why do you think you need to recompile the SDK?

[jordanbriere]

SourceMod seems to compile with the newer version of g++ (currently clang), so why do you think you need to recompile the SDK?

I vaguely remember various demangling issues for everything that is statically linked.

[Ayuto]

The new release is out and seems to work fine on my end.

@waldotf Could you please verify?

[waldotf]

Seems to be working fine for me. Closing.