mirror of
http://mpg123.de/trunk/.git
synced 2025-10-31 01:25:33 +03:00
83 lines
3.4 KiB
Plaintext
83 lines
3.4 KiB
Plaintext
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.
|