Bug#1063140: mpg123: NMU diff for 64-bit time_t transition
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.
Reply to: