Regarding largefile setup, client apps can be built three ways:

1. _FILE_OFFSET_BITS == 64        (header maps to mpg123_open_64)
2. _FILE_OFFSET_BITS == 32        (header maps to mpg123_open_32)
3. _FILE_OFFSET_BITS == <nothing> (header maps to mpg123_open)

The libmpg123 build needs to be prepared for everything. Also, it needs to keep
in mind the days before introducing large file support --- binaries should still
work with updated libmpg123. So, mpg123_open should always match what is the
default build on a platform without added settings. Those are the platform
variants:

1. 64 bit native system, long == off_t
libmpg123: mpg123_open
lfs_alias: mpg123_open_64 -> mpg123_open
lfs_wrap:  <none>

2. largefile-sensitive, long = 32, off_t = 64 (if enabled)
libmpg123: mpg123_open_64
lfs_alias: mpg123_open_32 -> mpg123_open
lfs_wrap:  mpg123_open -> mpg123_open_64

3. largefile, long = 32, off_t = 64 (FreeBSD)
libmpg123: mpg123_open
lfs_alias: mpg123_open_64 -> mpg123_open
lfs_wrap:  <none>

This is what mpg123 does in version 1.15.4 and it works. Well, for cases 1
(Linux/Solaris x86-64) and 2 (Linux/Solaris x86). Case 3 needs to be added
properly. Actually, let's have a second look at case 2: When mpg123 is built
with --disable-largefile:

2a. largefile-sensitive, mpg123 built with off_t = 32 == long
libmpg123: mpg123_open
lfs_alias: mpg123_open_32 -> mpg123_open
lfs_wrap:  <none>

So, this is still correct. Now, what about case 3? What does mpg123 do
currently, as of 1.15.4?

3a. largefile, long = 32, off_t = 64 (... and mpg123 not really aware of that)
libmpg123: mpg123_open
lfs_alias: mpg123_open_32(long) -> mpg123_open(off_t)
lfs_wrap:  <none>

This is _wrong_. Luckily, this does not cause binary compatibility issues, as
mpg123_open_32 won't be called by anyone unless that someone tries to define
_FILE_OFFSET_BITS=32, which is nonsense. Perhaps old FreeBSD binaries before
LFS times? Well, back then, there was no libmpg123. So let's ignore that case.
The issue at hand is that the alias should be from mpg123_open_64 to
mpg123_open, for clients that insist on defining _FILE_OFFSET_BITS=64.

The change needed now is to fix the naming and also change the type the
alias functions use: It is not long int anymore!

Let's revisit case 1 for a moment: My old lfs_alias.c provides for the case
lfs_alias: mpg123_open -> mpg123_open_64. Is that actually possible?
What means enforcing _FILE_OFFSET_BITS=64 from the outside, which _could_
happen when libmpg123 is included someplace and folks are on the wrong side
of paranoid regarding this. So, there is

1a. 64 bit native system, long == off_t = 64 and _FILE_OFFSET_BITS=64
libmpg123: mpg123_open_64
lfs_alias: mpg123_open -> mpg123_open_64
lfs_wrap:  <none>

(Works also for any system with long == off_t in any width)
Likewise, there is largefile-sensitive system with enforced 32 bits:

2b. largefile-sensitive, mpg123 with enforced _FILE_OFFSET_BITS=32
libmpg123: mpg123_open_32
lfs_alias: mpg123_open -> mpg123_open_32
lfs_wrap:  <none>

All cases are supported with this significant change from 1.15.4:
Make the aliases use a defined lfs_alias_t, which can be long or off_t,
depending on what is the default type for offsets on the platform.
Folks who try _FILE_OFFSET_BITS=32 on a system that only supports
64 bit get a linking error during mpg123 build (from the _64 aliases),
which I consider to be a feature.

I salute anyone who is not confused after reading this.