A summary of the current situation: There are historic programs and libraries relying on the old FILE structure. These programs and libraries assume that any 4-byte aligned FILE structure is acceptable, because that was the case with libio 2.0
Most programs and libraries are compiled with libio 2.1. At least on sparc, this means that FILE objects now need to be aligned on an 8-byte boundary. The compiler assumes this alignment when generating code using libio 2.1 (or newer) headers. The alignment difference is the cause that even though glibc maintainers took a lot of effort to make the old and the new structure compatible, there can be unexpected problems on sparc, because it seems like the alignment issue was not considered at that time. There is no silver bullet - either we have an 8-byte alignment requirement, which keeps compatibility with all libio 2.1 code, or we relax the requirement to 4-byte alignment (by splitting the 64-bit offset field and implementing the 64-bit-arithmetic by hand), which will re-enable full compatibility with libio 2.0 code. Especially as libio 2.0 and libio 2.1 libraries can be dynamically mixed, and all code expects that FILE* pointers of the old and new variant are interchangable for the narrow-character interface, there is some mess outside of glibc already that can never be fixed. A way to minimize the symptoms of this bug is to notice that most, if not all, FILE structures are allocated inside libc. As long as libc code controls the address of FILE objects, it can ensure 8-byte alignment, even for the legacy structures. So my recommendation is: 1. keep not forcing old FILE* to be 8-byte-aligned Forcing it would make the legacy function (versioned GLIBC_2.0) unable to cope with (unaligned) objects they currently can cope with 2. do force 8-byte-alignment on the legacy stdin/stdout/stderr This will make the legacy standard streams compatible with current code 3. do force 8-byte aligment on functions generating FILE structures (like fopen), even in the legacy interface. This will make all stream objects allocated in libc functions (which probably will be all stream objects you encounter) compatible with current code. I am completely aware (as pointed out above) that this is not a perfect fix, but it should be a good enough fix that no observable problems occur, even if you mix libio 2.0 and libio 2.1 code. And finally: 4. implement a lintian check that shared objects (programs and libraries) importing any GLIBC_2.1 or later versioned symbol also contain an *unversioned* export of _IO_stdin_used on those architectures where libio 2.0-compatibility is enabled (for example i386, but not amd64). In my oppinion, this bug is definitely not release critical, because the only thing that is broken is a compatiblity layer for programs more than 10 years old. This would count as "a particular option (or menu item)" of libc6, furthermore not affecting the "core functionality of the package". So the priority should be normal or minor. A build process that mangles the export of _IO_stdin_used is (as defined by the libc ABI, even if not explicitly written down) broken. The bug in this case was caused by such a kind of broken build process in the Mozilla applications that already has been fixed. We are still waiting for a real manifestation of the original bug, which should occur with libio 2.0 programs only. Regards, Michael Karcher -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
