Search Unity

  1. Dismiss Notice
  2. All Pro and Enterprise subscribers: find helpful & inspiring creative, tech, and business know-how in the new Unity Success Hub. Sign in to stay up to date.
    Dismiss Notice
  3. Dismiss Notice

Bug [2019 LTS] Symbol conflict between FMOD Studio and UnityPlayer.so

Discussion in 'Linux' started by flibitijibibo, Nov 19, 2020.

  1. flibitijibibo

    flibitijibibo

    Joined:
    Jan 14, 2019
    Posts:
    1
    When using Unity 2019.4 LTS and FMOD Studio 1.10.x, the audio engine will fail with an ERR_HEADER_MISMATCH failure, despite the C# wrapper matching the native libraries. As it turns out, the bug is 2019.3's introduction of the -rdynamic flag to the game's main binary; instead of using libfmod.so's code, it instead attempts to use the old version of FMOD Ex found inside Unity!

    This is a pretty serious issue because it's unsolvable in both directions, at least from the end user's perspective. We can't use the default behavior because of this, and forcing libfmod.so with LD_PRELOAD either crashes immediately on start when Unity attempts to start its own audio engine or crashes on exit when dl-fini for Unity tries to free using libfmod.so's Free function (though why it tries to free anything for an engine it doesn't use isn't clear to me). Even if you factor in the FMOD 2.x series' workaround for this, the -rdynamic change is an extremely serious regression for backward compatibility, and Linux compatibility in particular - I am already aware of at least one other Unity game that decided not to ship a Linux version at all specifically because of this bug and this bug exclusively.

    While trying to hack around this I think I've come up with a solution that hopefully Unity can do for a future release: Would it be possible to build Unity with the internal FMOD library compiled as hidden? As long as they're compiled with something like -fvisibility=hidden, #pragma GCC visibility push(hidden), whatever it takes to make it so Unity's FMOD Ex is only used by Unity and prevents FMOD Studio from accessing the wrong symbols should resolve the bug. As far as I am aware, games are not allowed to use Unity's internal FMOD entry points, so this should not introduce any compatibility issues.

    The bug can be reproduced with the following steps, using any FMOD release from the 1.10 series:

    https://qa.fmod.com/t/unity-2019-3-0f6-err-header-mismatch/15427/6
     
unityunity