Fix missing template instantiation in RelWithDebInfo builds

[miranda]

🍰 Pullrequest

Fixes a linking issue on Linux for VisitAllObjects in RelWithDebInfo (-O2 -g) and ASan (-fsanitize=address) builds by ensuring CellImpl.h is included in TargetedMovementGenerator.cpp.

Proof

• Build tested successfully on Linux (RelWithDebInfo, Debug, Release).
• Confirmed that missing template instantiation was the cause of the issue.

Issues

• No existing issue reports for this specific problem.

How2Test

1. Compile with -DCMAKE_BUILD_TYPE=RelWithDebInfo -fsanitize=address on Linux.
2. Before this fix: Linker fails with undefined reference to VisitAllObjects.
3. After this fix: Compiles and links successfully.

Todo / Checklist

• Ensure VisitAllObjects is correctly instantiated.
• Fix Linux linker error.
• Tested across different build types.

[insunaa]

What is the problem exactly?
Is this just a PCH=Off build issue?
Edit: Shouldn't be. GH Actions pipeline builds mangos-tbc just fine even with PCH off https://github.com/cmangos/mangos-tbc/actions/runs/13573268449/job/37943344030#step:6:653
Edit2: I can't reproduce the issue. I built with -fsanitize=address and it compiles and links just fine.

[miranda]

On Linux? I tried many variations and they fail linking. For example:

cmake ../mangos-tbc \
    -DCMAKE_CXX_FLAGS="-D_GLIBCXX_USE_TBB_PAR_BACKEND=1 -ltbb -fsanitize=address -fno-omit-frame-pointer" \
    -DCMAKE_C_FLAGS="-fsanitize=address -fno-omit-frame-pointer" \
    -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address" \
    -DCMAKE_INSTALL_PREFIX=~/cmangos/run \
    -DPCH=1 \
    -DDEBUG=0 \
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DBUILD_PLAYERBOTS=ON \
    -DBUILD_AHBOT=ON \
    -DFETCHCONTENT_FULLY_DISCONNECTED=ON

the result is:

[100%] Linking CXX executable mangosd
/usr/bin/ld: ../game/libgame.a(TargetedMovementGenerator.cpp.o): in function ChaseMovementGenerator::FanOut(Unit&)':
/home/serqetry/projects/cmangos-dev/public/mangos-tbc/src/game/MotionGenerators/TargetedMovementGenerator.cpp:442:(.text+0x1f031): undefined reference to void Cell::VisitAllObjects<MaNGOS::UnitSearcherMaNGOS::AnyUnitFulfillingConditionInRangeCheck >(WorldObject const*, MaNGOS::UnitSearcherMaNGOS::AnyUnitFulfillingConditionInRangeCheck&, float, bool)'
collect2: error: ld returned 1 exit status
make[2]: *** [src/mangosd/CMakeFiles/mangosd.dir/build.make:235: src/mangosd/mangosd] Error 1
make[1]: *** [CMakeFiles/Makefile2:656: src/mangosd/CMakeFiles/mangosd.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

If DDEBUG=1, this doesn't happen. It's only with RelWithDebInfo. But adding that include fixes it.

[insunaa]

Why are you using tbb? Also why are you setting DEBUG to 0?

cmake .. -DBUILD_AHBOT=false \
-DBUILD_GAME_SERVER=true \
-DBUILD_LOGIN_SERVER=true \
-DBUILD_SCRIPTDEV=true \
-DUSE_ANTICHEAT=false \
-DBUILD_EXTRACTORS=true \
-DBUILD_PLAYERBOTS=false \
-DSQLITE=true \
-DCMAKE_INSTALL_PREFIX=../bin \
-DCMAKE_EXPORT_COMPILE_COMMANDS=true \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DDEBUG=On \
-GNinja \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
-DPCH=ON \
-DBUILD_RECASTDEMOMOD=false \
-DBUILD_METRICS=true \
-DCMAKE_CXX_FLAGS="-fsanitize=address -fno-omit-frame-pointer" \
-DCMAKE_C_FLAGS="-fsanitize=address -fno-omit-frame-pointer" \
-DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address -fno-omit-frame-pointer"

compiles and links just fine

[miranda]

I could not get cmangos to build at all in my Garuda Linux environment w/ i7-13700K CPU without using tbb. Is there a reason I shouldn't use tbb?

I am using DDEBUG=0 because it runs much faster but I still get address sanitize and stack trace with RelWithDebInfo.

And can you explain why #include "Grids/CellImpl.h" should not be added? If it’s required for proper linkage in some configurations, shouldn’t it be included explicitly?

[insunaa]

Well we don't officially support tbb and we've had several bug reports involving CMaNGOS compiled against tbb in the discord. I can't speak to how valid they are, however.
As for including CellImpl.h in genuinely can't reproduce your issue. I don't mind it getting included I guess, but I don't see why it's fixing your linking issue.

[miranda]

Ok thanks, that makes sense about tbb, but like I said I need it to be able to build. This is only the case on my 13700K machine, it builds fine without tbb on my vanilla Arch Linux Ryzen 5800X... not sure why this is the case, but it was a solution for my Intel machine.

The function Cell::VisitAllObjects is declared in Cell.h but only defined in CellImpl.h. If CellImpl.h is not explicitly included, the function template isn’t instantiated correctly, leading to an undefined reference error at link time. Seems like the issue may not appear for everyone because PCH can mask missing includes by precompiling headers from other parts of the codebase... but fixing it anyway would be nice so there aren't any configurations that won't link.

[evil-at-wow]

There seem to be two different things at play here.

First, the use of tbb. Using tbb is not entirely a user choice any more these days. GCC uses it for the parallel algorithm these days (because it was a contribution by Intel). See for example the documentation on https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017, and in particular note 3 there:

Note 3: The Parallel Algorithms have an external dependency on Intel TBB 2018 or later. If the header is included then -ltbb must be used to link to TBB.

As far as I'm aware, we're not using tbb nor the parallel algorithms directly, so there's no need for tbb from our side. But I vaguely remember someone mentioning an issue where something included <execution> indirectly in a build causing issues when not linking with libtbb. I forgot what it was, but my guess would be a boost library like asio or something like that. I don't know Garuda Linux, but maybe the story is similar there (or perhaps -D_GLIBCXX_USE_TBB_PAR_BACKEND=1 triggers it unconditionally?).
Either way, I don't see your use of tbb as problematic; you are also passing '-ltbb' as the documentation says you should in those cases, and your issue is not that you get linker errors because of unresolved tbb symbols.

Then there's the actual undefined reference you get. A missing include leading to a missing template instantiation makes sense. I can't immediately see why 'release vs debug' makes a difference (I'll check because I'm genuinely curious now), but I do agree that necessary and missing includes should be added.

[miranda]

Yes, I'm using -D_GLIBCXX_USE_TBB_PAR_BACKEND=1 -ltbb

What you are saying about GCC sounds right. I think it was boost-related linking problems, but it was months ago that I figured out I needed to adjust my cmake options to use tbb in order to get it to link on this machine... and haven't had a problem since. But it was never a problem on my Ryzen machine, it links everything fine with or without tbb, with the same GCC and libraries. It's strange.