20 Oct
2013
20 Oct
'13
7:16 p.m.
On Friday 18 of October 2013 17:23:21 Michele Calgaro wrote:
HI there,
is anybody aware of any good reason why tdelibs14-trinity and some other
packages have a very strict dependency on binutils in Debian Jessie and
Wheezy (and I suspect also on previous versions and in Ubuntu, even though
I didn't check)? For example I get dependencies such as:
binutils (>= 2.23.52.20130828), binutils (<< 2.23.52.20130829).
The problem with such kind of dependency is that when binutils is updated,
I need to do a full rebuild of TDE before I can update the binutils package
on my machine. After the full rebuild is completed, everything can be
updated, but I don't see the reason for having the '<<' part of the
dependency since it doesn't seem to affect anything: TDE builds with both
the old and the new binutils package.
So I am wondering if such strict dependency is intentional or if it is
something that we are dragging along from the past (perhaps because of a
broken or incompatible binutils version in the past).
If there isn't any particular reason, I will open a bug report in a few
days about this point.
Thanks
Michele
Hi Michele,
explanation of very tight depending on binutils is simple:
For easier detection of particular bug were incorporated into kdesktop_lock
function to generate backtrace (commit 786e248c - tdebase). Later the same
function incorporated into tdeio (commit a166b1da - tdelibs). And lastly,
both these functions were replaced with improved function kdBacktrace in
kdebug (commit a5ba7ad7 - tdelibs).
This implementation uses for generate backtraces library bfd from binutils.
And this library is causing this problem with a very tight dependency. This
library is always one specific version and does not allow even a small
difference. For example on Debian Squeeze: libbfd-2.20.1-system.20100303.so
For this reason, wherever it is used kdBacktrace => is dependent on libbfd =>
is so strict dependency on a particular version of binutils.
The solution would be if instead of linking the library dynamically loaded.
But it can be a problem when that will happen in a crash handler => in an
emergency situation.
--
Slavek