http://bugs.winehq.org/show_bug.cgi?id=20042
--- Comment #36 from Thomas Orgis thomas-forum@orgis.org 2010-02-11 09:06:50 --- I am not sure what to respond to this. I do have the suspicion that mpg123 is not alone with the issue of having to prevent bad combinations of applications and libraries using 32 bit or 64 bit off_t. Be reminded that the header would look identical for i386 and x86-64 would 64 bit off_t be the default on a 32bit build. This whole mess mainly arises because a default build of libmpg123 enables 64 bit offsets via configure but when you simply build a program using libmpg123 and do not specify special compiler flags, your program will use a 32 bit off_t.
Without the check I built into the header, this would cause funny unspecified behaviour when using the API that expects 64 bit offsets. I assume that there are libraries that let that just happen... and this is mostly not an issue because distributions carefully build everything with largefile support(?). In hindsight, I perhaps should have not added that check. Most people would not notice and be happy, some people would have strange issues...
Now, for the option of implementing both 32 bit and 64 bit API, just like libc. Is it really a good idea to recreate that hack in each library relying on the "magic" of off_t? It seems like the other real option is to use yet another custom typedef for offsets and internally convert between that and the actual off_t the library uses. That includes handling EOVERFLOW and friends. It is not fun. I'd rather avoid such cruft before doing it incorrectly. And also, what will a user of the library do? Especially if the user uses other libraries that yet again have other custom file offset types... there will be blind casts without checking.
I do not feel comfortable having to devise header machinery that corretly maps functions to wrappers that handle 32 bit / 64 bit conversion... I will need to add architecture-dependent macros... see that there only is 64 bit off_t on an x86_64 system; detect i386 systems that need _32 and _64 functions... and then prevent this all do do something on *BSD, where off_t is just 64 bits, period. Such a header would not be platform-independent. It would be specific to the set of platforms that are covered in the preprocessor machinery.
But I want to have my code portable, using off_t and detecting at configure-time if large file support shall be enabled is portable. Every line of complication to the header makes it more likely that some configuration will be broken without need.
I see the problem really with the distributions: When they do multilib, they need to store both verisons of the header file, each matching its library. For a distribution it is trivial to install a wrapper in /usr/include that includes a 32 bit or a 64 bit header depending on x86 / x86-64 (SPARC / SPARC64, PPC / PPC64) build being selected. That can be automated in the distribution's build system. They know what architectures / ABIs they support. They know what default compiler they support.
Until such proper solution is in place, the workaround I offered should do the trick. When wine is configured with largefile support for 32 bit code, it just needs to add -DMPG123_FORCE_LARGEFILE=_64 to its CPPFLAGS. That won't work for mpg123 versions < 1.10.1, but we cannot change the past, anyway.
If this is really not acceptable, I am open to further discussion...