[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#422317: marked as done (readlink return type changed without backwards-compatibility symbol)

Your message dated Sun, 6 May 2007 00:04:42 +0200
with message-id <20070505220440.GA7509@amd64.aurel32.net>
and subject line Bug#422317: readlink return type changed without backwards-compatibility symbol
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: checkinstall
Version: 1.6.1-2
Severity: serious

Hi Felipe,

The latest version of checkinstall is failing to build on alpha and ia64
because you are build-depending on libc6-dev, which is not the right package
on these archs (or on non-Linux archs).  If there is a reason you need this
versioned build-dep on libc6-dev (which is not explained in the changelog),
please fix the build-dep to be architecture-conditional, build-depending on
libc6.1-dev on alpha and ia64 instead of on libc6-dev.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

--- End Message ---
--- Begin Message --- 
On Sat, May 05, 2007 at 11:57:43AM +0200, Aurelien Jarno wrote:
> 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.
> 

00:00 < vorlon> aurel32: if you've tested it and found that it's not a bug, I don't need to agree :)
00:01 < aurel32> vorlon: ok, I am closing it then 
00:01 < vorlon> your explanation makes sense anyway, but I don't know any better one way or another

Closing the bug with this mail.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

--- End Message ---
Reply to: