This still affects 2.3.3+dfsg-0ubuntu3, which is the version in plucky through tenacious. debian/rules on ubuntu/devel still has `-DCMAKE_CXX_FLAGS="$(CXXFLAGS) -DDEBUG=0 -D_DEBUG=0"`. Building gz- rendering from source on resolute (arm64) gives the same `undefined symbol: _ZThn944_N4Ogre7HlmsPbs19_changeRenderSystemEPNS_12RenderSystemE` when the ogre2 plugin is loaded.
The reason for the offset difference: OgrePlatform.h only checks whether the macros are defined, not their value: ``` # if defined(_DEBUG) || defined(DEBUG) # define OGRE_DEBUG_MODE OGRE_DEBUG_LEVEL_DEBUG ``` So `-DDEBUG=0 -D_DEBUG=0` builds the library with OGRE_DEBUG_MODE = OGRE_DEBUG_LEVEL_DEBUG (3 by default), while a consumer built with only NDEBUG gets OGRE_DEBUG_LEVEL_RELEASE (0). With a non-zero OGRE_DEBUG_MODE, IdString has an extra `char mDebugString[32]` member (OgreIdString.h). Hlms has two IdString members (`mShaderSyntax`, `mTypeName`), so it is 64 bytes larger in the library than in its users, which is exactly the difference between the thunk offsets 1008 and 944. Until the package is fixed, building the consumer with `-DOGRE_DEBUG_MODE=3` works around it; with that, gz-rendering's ogre2 plugin loads and the gz-sensors tests pass with ogre2. Dropping the two flags from debian/rules, as the linked merge proposal does, should fix it for everyone. Assisted-by: Claude:claude-opus-5-5 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2063359 Title: Use of NDEBUG in d/rules for 2.3.3+dfsg-0ubuntu2 on Noble generates an incompatible ABI To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ogre-next/+bug/2063359/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
