Hi Sebastian, thanks for not escalating on the anger that has shown through the end of my last reply. It really seems to be an endless stream of pain that results from once having put off_t into public API. This is the message I have to any developer: Do not put types into your API that could depend on compile-time settings! (Even, and especially, if the libc does that and you _think_ it could be handled.)
At least it is clear to me now that time_t is only a minor detail. You are switching system ABI in enabling LFS and 64 bit time_t. This is a decision that Debian made and also, you are planning to make this transition in-place, instead of calling it a new arch. From my point of view, then, the mpg123 build works as designed: It sees a system with fixed 64 bit off_t and drops any 32 bit off_t support from the ABI. Since you do this switch on upgrade of existing systems, you need to handle that in the packaging system, either via versioning or the suffix you designed. Fine, then. But there is a consideration for user-compiled code in the system. The important breakage here is not that the _32 suffix symbols are missing. It is rather that the non-suffixed ABI suddenly changed. If a user program that just was built without _FILE_OFFSET_BITS being set for the old library is started using the replaced libmpg123 binary, it finds the mpg123_tell() symbol, but suddenly faces memory corruption as that function now writes 64 bits instead of 32 bits to the return address. A clean transition, IMHO, would mean that you have to change sonames so that it is clear that the new libraries have a different ABI. Silently breaking user binaries is a bothersome issue to me. Breaking them with 'library not found' errors is obvious. Subtle errors and crashes through memory corruption are not. I'd rather have that situation avoided. One solution would be to have a library mode that drops both mpg123_tell() mpg123_tell_32() and only retains mpg123_tell_64() as well as the recently added actual mpg123_tell64() using int64 instead of off_t. If _FILE_OFFSET_BITS is defined system-wide (in gcc internal headers / spec file), new builds will pick up mpg123_tell_64() and not notice any missing symbols. With this, you only have the missing symbols for clear errors at least. On the other hand, providing the wrappers for 32 bit is a possible option. The code is there … but … thinking … no. It doesn't help. Having a 32 bit mpg123_tell() in a system defaulting to 64 bit off_t is really confusing. Can you do a scan over all depending packages and ensure that they only use _64 suffixed symbols (where there is a pair like mpg123_tell() and mpg123_tell_64())? Even if you change the package name for the transition, I'd like to ensure that the new library does cause controlled failure due to linker errors instead of subtle runtime breakage. Would you be willing to add something along ./configure --disable-suffixless-abi to your builds once I implement that? This would double the count of dropped symbols, but avoid the subtle runtime ABI breakage. Alrighty then, Thomas PS: Please observe my comments about --with-cpu on ARM, bug #1067562.