| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182 |
- 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.
|
