On Fri, May 04, 2007 at 05:55:23PM -0700, Steve Langasek wrote: > 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. >
I think this is wrong. Whatever the endianness, the 32-bit registers map to the 32 least significant bits of the corresponding 64-bit registers. This way for example a 64-bit Sparc CPU is still able to execute 32-bit code, even if its registers are 64-bits. In addition I have made a few tests on sparc64 that shows that there is no breakage. I guess this bug could be closed, please close it if you agree. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
