[kde-linux] Latest ktorrent

[Duncan]

jd1008 posted on Sun, 14 Jun 2015 16:36:57 -0600 as excerpted:

> OK,
> so I did find the how-to-build   simple instructions.
> I installed all the required packages and ran cmake in the build dir,
> and that worked just fine.
> 
> Ran make and it belched the following error:
> 
> 
> [  3%] Building CXX object src/CMakeFiles/ktorrent.dir/util/functions.o
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:
> In function ‘QString bt::BytesToString(bt::Uint64)’:
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:228:37:
> error: no matching function for call to
> ‘KLocale::formatByteSize(bt::Uint64&, int)’
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:228:37:
> note: candidate is:
> In file included from
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:35:0:
> /usr/include/kde4/klocale.h:479:11: note: QString
> KLocale::formatByteSize(double) const
> /usr/include/kde4/klocale.h:479:11: note:   candidate expects 1
> argument, 2 provided
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:
> In function ‘QString bt::BytesPerSecToString(double)’:
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:234:49:
> error: no matching function for call to
> ‘KLocale::formatByteSize(double&, int)’
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:234:49:
> note: candidate is:
> In file included from
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:35:0:
> /usr/include/kde4/klocale.h:479:11: note: QString
> KLocale::formatByteSize(double) const
> /usr/include/kde4/klocale.h:479:11: note:   candidate expects 1
> argument, 2 provided
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:235:2:
> warning: control reaches end of non-void function [-Wreturn-type]
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:
> In function ‘QString bt::BytesToString(bt::Uint64)’:
> /usr/src/redhat/NON-RPM/network-apps/ktorrent/libktorrent-1.3.1/src/
util/functions.cpp:229:2:
> warning: control reaches end of non-void function [-Wreturn-type]
> make[2]: *** [src/CMakeFiles/ktorrent.dir/util/functions.o] Error 1
> make[1]: *** [src/CMakeFiles/ktorrent.dir/all] Error 2 make: *** [all]
> Error 2

OK, I don't claim to be a dev but... I am a gentoo ~arch (aka testing/
rawhide) user, and of course on gentoo, we build from sources using 
scripts, so with over a decade on gentoo ~arch I've gotten a bit of 
practice chasing down build errors. =:^)

1) What version of gcc, or are you building with something else (what)?  
Newer versions tend to be stricter and omit warnings and errors where 
previous versions worked fine.  Those get fixed upstream over time, but...

FWIW, gcc 4.9.2, here (on gentoo/~amd64).

However, 1 argument library function vs. 2 provided by caller looks like 
something that should always be a problem, so I doubt that's it.

2) What version of whatever package owns /usr/include/kde4/klocale.h ?

3) If you know how to check (or can figure out), does that package patch 
that file in any way?

Seems there's a basic function calling incompatibility between the 
library supplying that function, and what the libktorrent sources are 
wanting.  It's very likely either a version incompatibility that there's 
a patch for, or your package provider patched it and a compatible patch 
needs applied to libktorrent.


FWIW, a quick look here says:

a) gentoo doesn't patch libktorrent (same version, 1.3.1).

b) gentoo uses the path /usr/include/klocale.h (no kde4 subdir here), and 
that file belongs to kdelibs.

c) I currently have kdelibs-4.14.9 installed.  That should be pretty new 
from upstream, as gentoo/kde is pretty much on the ball.

d) gentoo does patch kdelibs, but none of the patches include the word 
klocale.h, so that file isn't patched.

e) In my kdelibs-4.14.9 version of klocale.h, I see two definitions for 
formatByteSize.

There's the original single-argument version, and then the second, with a 
the comment including a note saying since 4.4, the function is 
"overloaded" (which I've seen used in C++ context but being more an admin 
than a dev I have only a rough idea what it actually means, I _think_ 
basically what we see here, a second definition available, with C++ able 
to choose which one based on number of parameters actually used, etc), 
with four arguments possible, but the last two appear to have default 
values and thus be optional.

So if there's a single argument given, it would choose the first 
definition.  If there's two, three or four arguments given, it would 
choose the second, filling in the last two if they aren't there.

So... I'm guessing your kdelibs (or whatever package provides that file 
there) is pre-4.4.  You'll need to upgrade it to something newer, so the 
library understands the 2-4 argument version of the call.

Of course in doing so you may find you need to update all of kde to a 
similar version, altho in theory at least, kdelibs should be backward 
compatible, but not forward compatible, thru the entire 4.x series.  So 
at least in theory, you should be able to build a kdelibs 4.14.9 and have 
it provide all the old functions necessary for older kde4 series packages 
built on top of kdelibs.

Personally, if you're on a kde4 earlier than 4.5 as it seems you are, 
while the latest 4.14.x with 4.11.x workspace, I'd *VERY* *STRONGLY* 
recommend upgrading to at *LEAST* 4.5, as from my experience, despite 
claims to the contrary 4.2 was still alpha quality (forget not working, 
many features not even implemented yet), 4.3 was rough beta quality (most 
features implemented but some still broken and most still quite rough 
edged), 4.4 was /finally/ getting to what I'd call release-candidate 
quality (everything's implemented, most features work and there's now an 
evident smoothness, but some functionality may still be buggy 
particularly in corner cases), and only with 4.5 did kde4 /finally/ reach 
what I'd call release quality.

So if you're on anything kde4 earlier than 4.5, from my perspective, 
you're still on what should have been pre-release kde4, and you really 
owe it to yourself to get on something newer, at least 4.5, which IMO 
finally reached release quality.

Meanwhile, note that 4.6 brought some big dependency changes, no more 
HAL, etc, so it's likely going to require far more upgrades if you 
upgrade beyond 4.5.  So 4.5 really does seem to be the magic version, if 
you're running a kde4 older than that and want to do the minimum 
reasonable upgrade.  Anything older than that is, IMO, substandard, and I 
simply wouldn't settle for it, switching distro if necessary to get at 
least a reasonable kde 4.5.

Of course the other alternative would be to try a (lib)ktorrent version 
older than 4.3.1, but newer than what you had before, trying for a 
version that still works with your older klocale.h.  Unfortunately, with 
ktorrent.org down, it might be difficult to find the sources...  

FWIW, it has been over a decade ago now, but before gentoo, I used to run 
the rpm-based mandrake.  I found rmpfind.net an incredibly useful 
resource for older or newer versions of various packages.  Obviously I've 
not used it for that in over a decade now, but I still use it 
occasionally for tracking down what package might provide a particular 
file I don't have installed, for instance, or more often, for cases such 
as this.

Seems rpmfind.net has srpms (Fedora Secondary Rawhide Sources) for 
libktorrent back to 1.2, but for binary rpms unless you're on some exotic 
arch, it appears you're out of luck for earlier than 1.3.1, as that's all 
they appear to have for i586/i686/x86_64.  But you could try the srpms 
for libktorrent 1.2, and the parallel srpms for ktorrent itself, and hope 
it's early enough to still make the single-argument call.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman