Bug#561852: apt: Method http has died unexpectedly (undefined symbol:)
David Kalnischkies writes:
> Hi George Danchev,
>
> 2009/12/29 George Danchev <danchev@spnet.net>:
> > It turns out that some previous version of apt (<= 0.7.24) provide
> > libapt-pkg- libc6.9-6.so.4.8.1 shared object, which according to objdump
> > -T and readelf -s do not provide the missing symbol in question
> > (_Z14maybe_add_authR3URISs).
>
> Correct, maybe_add_auth was added in rev 1561.3.1 of the debian-sid branch.
> (Seems to be we forget to bump the minor abi while trying hard to not break
> the major abi) but as the library and the user (method/http) are shipped in
> the same package the error is still a bit strange, especially as the http
> method is the most used acquire method and the call to maybe_add_auth is
> unconditional, so many (read: all) users should have faced this problem...
Yes, I agree with that logic and actually very few users reported about
behavior like that.
> So is this somehow reproducible?
Since there are so many upgrade paths, I haven't been able to reproduce that
starting to upgrade apt from a clean lenny, I tried several combinations with
no luck. I wonder if the resetted shared object versioning has something to do
with it, e.g:
apt < 0.7.24 libapt-pkg- libc6.9-6.so.4.8.0
apt = 0.7.24 libapt-pkg- libc6.9-6.so.4.8.1
and then again:
apt = 0.7.25 libapt-pkg- libc6.9-6.so.4.8.0
that being said, I don't see many chances for libapt-pkg- libc6.9-6.so.4.8.1
and a previous version libapt-pkg- libc6.9-6.so.4.8.0 (with that symbol
missing) to be left in place with a symlink and latest apt-get binary which is
trying to resolve the missing symbol.
(I reproduced it artificially extracting and putting in place libapt-pkg-
libc6.9-6.so.4.8.1 from apt 0.7.24 when apt 0.7.25 was installed, but this is
not so realistic as scenario)
> I would personally prefer to understand why this happen at all
> before closing the bug to be able to avoid such problems in the future.
Yes, I can see your reasons...
--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: