music_mpg123.c: disable _FILE_OFFSET_BITS suffixes on libmpg123 calls.

[sezero]

Avoids libmpg123's terrifying mess. Useful if mpg123_shared is disabled
and if SDL_mixer is built with _FILE_OFFSET_BITS=64.

If accepted, will cherry pick to SDL2 branch too (also to release-2.8.x)

( CC @smcv )

[smcv]

Useful if mpg123_shared is disabled

We do this in Debian to get "normal" shared library dependencies in an environment where it's easy for the package manager to enforce them. I assume this is why I was pinged?

and if SDL_mixer is built with _FILE_OFFSET_BITS=64

We avoid doing this on Debian i386 for legacy binary compatibility (to avoid breaking the ABI of old libraries), and it's a no-op on x86_64 (offsets are always 64-bit on any reasonable 64-bit architecture), so the Steam Runtime is unaffected.

Debian armel and armhf (the surviving 32-bit non-i386 architectures), together with some unofficial ports like m68k, might conceivably be affected by whatever issue this is solving - but I don't see any compiler warnings in the armel or armhf build logs, so perhaps we dodged that particular bullet.

[smcv]

It might be more future-proof to explicitly call mpg123_seek64() and so on (without the underscore), which always use int64_t for offsets, and do not vary with the size of off_t.

[sezero]

Useful if mpg123_shared is disabled

We do this in Debian to get "normal" shared library dependencies in an environment where it's easy for the package manager to enforce them. I assume this is why I was pinged?

Yup

and if SDL_mixer is built with _FILE_OFFSET_BITS=64

We avoid doing this on Debian i386 for legacy binary compatibility (to avoid breaking the ABI of old libraries), and it's a no-op on x86_64 (offsets are always 64-bit on any reasonable 64-bit architecture), so the Steam Runtime is unaffected.

Debian armel and armhf (the surviving 32-bit non-i386 architectures), together with some unofficial ports like m68k, might conceivably be affected by whatever issue this is solving - but I don't see any compiler warnings in the armel or armhf build logs, so perhaps we dodged that particular bullet.

OK, that's great

It might be more future-proof to explicitly call mpg123_seek64() and so on (without the underscore), which always use int64_t for offsets, and do not vary with the size of off_t.

That would forcibly require MPG123_API_VERSION >= 48 (mpg123 >= 1.32.0), but something to think about.