clone 422213 -1 reassign -1 libc6-sparc64 found -1 2.5-2 retitle -1 readlink return type changed without backwards-compatibility symbol thanks
On Fri, May 04, 2007 at 07:58:18PM -0400, Felipe Sateler wrote: > On Friday 04 May 2007 19:36:51 you wrote: > > On Fri, May 04, 2007 at 01:17:37PM -0400, Felipe Sateler wrote: > > > > If there is a reason you > > > > need this versioned build-dep on libc6-dev (which is not explained in > > > > the changelog), > > > It (sort of) is explained: the last line in the changelog says: > > > * Correct the readlink definition to match the newer 2.5 glibc: now > > > return a ssize_t instead of an int. > > > I think it is necessary since (I think) this changes the ABI: readlink in > > > 2.5 returns a ssize_t whereas previously it returned an int. This causes > > > no problem when sizeof(ssize_t) == sizeof(int) (which is the case in > > > i386), but it causes a FTBFS when used in 64 bit archs. This change was > > > made because there were bugs reported upstream for a FTBFS on 64 bit > > > archs. > > Ok. Well, I would've gone with an autoconf check instead of a versioned > > bulid-dependency in that case, but your choice. :) > This packages doesn't use autoconf, and autotooling it just for this doesn't > seem worth the while (specially since I don't know autotools very well). Heh, ok. > Also, wouldn't there be breakage if the return tipe is of different sizes > (say it was compiled against glibc <2.5, but now I installed 2.5)? I guess this relates to /usr/lib/checkinstall/installwatch.so, which seems to be a preload wrapper? Honestly, it looks to me like checkinstall is very vulnerable to all *kinds* of breakage, because whereas glibc uses symbol versioning to prevent ABI breakage within itself, checkinstall provides only unversioned symbols -- so the most likely outcome is that any changes to one or more of these symbols will result in checkinstall failing to intercept all the right calls, either causing some actions to be overlooked or causing segfaults due to calls being incorrectly split between checkinstall and glibc. But as for whether this constitutes ABI breakage, glibc upstream hasn't marked it as such in the package, and all of my existing alpha and amd64 binaries seem to run just fine with the changed return value. I believe this is because, as little-endian architectures, reading the first 32-bits of the return value will give the right result for any reasonably-sized buffer. But on 64-bit big-endian architectures, such as ppc64 or sparc64, this will probably break. libc6-sparc64 2.5-2 doesn't appear to include a new readlink symbol. I think the glibc folks might want to take a look at this, to confirm whether there's ABI breakage here. Cloned & reassigned. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
