Linux: build under gcc 16 / Boost 1.91 / cmake 4 - #52
Open
KonTy wants to merge 5 commits into
Open
Conversation
Boost 1.86 split boost::process into v1 (the existing API) and v2 (a new one), and started exposing the v1 headers under boost/process/v1/. Boost 1.91 then dropped the unversioned forwarder headers, so on those versions only boost/process/v1/ resolves. Detect both layouts with __has_include and route through a tc_bp namespace alias so the only behavioural difference between old and new Boost is which header path we use. The minimum Boost version (1.74 / 1.78) is unchanged.
src/common/Asio/DeadlineTimer.h inherits from boost::asio::basic_deadline_timer, which is one of the symbols Asio gates behind !defined(BOOST_ASIO_NO_DEPRECATED). On older Boost releases this combination compiled because the gate wasn't applied to that header; on recent releases (observed on 1.91) the template is hidden when the macro is defined and the TC build stops linking. Drop the macro from the boost target. The deprecated APIs TC actually uses are limited to deadline_timer, which is what DeadlineTimer.h is about; everything else that the macro was guarding is already absent from the TC source tree.
Two small, independent fixes to the bundled jemalloc snapshot. safety_check.h declared safety_check_set_abort as taking void(*)(), but the implementation in safety_check.c (and every caller) takes a void(*)(const char*). gcc 16 rejects the incompatible function pointer conversion at call sites instead of warning. Update the header to match the actual signature. jemalloc_cpp.cpp called std::__throw_bad_alloc(), which is a libstdc++ internal helper and has been removed in recent libstdc++ releases. Replace with the standard 'throw std::bad_alloc()' form, which compiles on every supported toolchain.
sol2 is consumed through a precompiled header and resolves <lua.h> via whatever include path is in scope at the point sol2 is parsed. On distros that ship Lua 5.5 in /usr/include (Arch is the obvious one, but not the only one going forward), that header is picked up in preference to the Lua sources fetched into _deps/lua-src/, and sol2 then refuses to compile against the wrong version. Marking liblua's include directory as PUBLIC adds the fetched Lua sources to anything that links against liblua, which is what already happens in the rest of the consumer chain. The change has no effect on Windows (no system Lua) and no effect on distros that don't ship a competing lua.h.
|
Were similar commits made to base TC? As far as I was aware, base TC compiled already fine for arch. Also as a non-arch user, i can say that it default builds on a ubuntu, so this may be a arch specific issue |
|
just confirming that this is an issue with how outdated the trinity fork is, arch being rolling release does not comfortably allow older versions of boost without serious environment finagling which in general isnt really acceptable and also still requires some heavy modification of the build toolchain im gonna try building KonTy's fork just to make sure it works, but i would seriously recommend supporting this as arch has become a more popular setup for gaming with distros like cachyos |
|
fails to build with lua 5.5 packages installed, some funky stuff is happening with it attempting to fetch and use 5.4.4 but still defaulting to system defaults when trying to build sol2 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi,
These four small commits are what I needed in this TrinityCore fork to get
tswow building against a current Linux toolchain. I tested on Arch with
gcc 16.1, cmake 4.3, openssl 3.6, boost 1.91 and mariadb 12, but each
change is conditional or has a portable rewrite, so none of them should
affect a Windows or older-Boost build. Min Boost (1.74 Linux / 1.78
Windows) is unchanged.
I tried to keep every commit independently reviewable in case some are
fine and others need rework. Happy to drop, split, or rewrite any of them.
Boost 1.86 split boost::process into v1 (the old API) and v2 (a new one)
and exposed the v1 headers under boost/process/v1/. Boost 1.91 then
removed the unversioned forwarder headers, so on those versions only
boost/process/v1/ resolves. I added a __has_include guard at the top of
StartProcess.cpp that picks the right headers and routes the file's
existing usage through a tc_bp namespace alias. Old Boost goes down the
unversioned path exactly as before, new Boost goes down the v1/ path.
The only line change inside the function body is replacing
boost::process::close with tc_bp::close.
src/common/Asio/DeadlineTimer.h inherits from
boost::asio::basic_deadline_timer, which Asio hides when
BOOST_ASIO_NO_DEPRECATED is set. Older Boost releases were lax about
applying that gate to deadline_timer.hpp and the build kept working; on
1.91 the symbol disappears and DeadlineTimer.h stops compiling. I just
dropped the define. The other things the macro was guarding are not
referenced anywhere in the TC source tree as far as I could tell, but
if there's something I missed I'm happy to migrate the offending call
sites and put the define back.
Two tiny independent fixes to the bundled jemalloc snapshot.
safety_check.h declared safety_check_set_abort as taking void()() but
the implementation in safety_check.c takes void()(const char*). gcc 16
treats the incompatible function pointer at call sites as an error.
jemalloc_cpp.cpp called std::__throw_bad_alloc(), which is a libstdc++
internal helper and was removed in recent libstdc++ releases. I
replaced it with the standard "throw std::bad_alloc()" form. Both
changes compile on every toolchain I have access to.
sol2 is consumed through a precompiled header and resolves <lua.h> via
whatever include path is in scope at the point sol2 is parsed. On
distros that ship Lua 5.5 in /usr/include (Arch today, presumably more
of them over time) the system header wins over the Lua sources fetched
into _deps/lua-src/ and sol2 then refuses to build. I marked liblua's
include directory as PUBLIC so anything that already links against
liblua picks up the fetched headers as well. The change has no effect
on Windows and no effect on distros that don't ship a competing lua.h.
Context: the parent tswow repo has a matching PR at tswow/tswow#938 that
covers the build-script and helper-tool side of the same toolchain
update. Without these four changes here the TrinityCore subbuild stops
at the first of the four issues; with them the worldserver and
authserver build and run.
If the v1/ guard in (1) or the macro removal in (2) is uncomfortable as
written, I'm open to alternatives. Let me know what would land cleanest.