So I wondered how to figure out the problem. Digging around in libc gave some insight:

Say what? Will always fail? That explains…. but why?!
Apparently there is another libc library that normally gets used that DOES have the proper epoll support, it is in /lib/tls . Weren’t it that the tls dir was renamed because Xen complained about it, so it doesn’t get used.

No warnings. However, a quick workaround to test this conclusion with LD_PRELOAD:

Ha, that’s more like it. Yeah, it fails to start because I still have the beta 12 running in another dir, but it doesn’t give the error anymore.

Googling a bit to find some details on Slackware 11 and glibc gave me a discussion somewhere on a mailinglist that mentioned that the glibc in /lib was compiled against
2.4 headers, while the /lib/tls version was compiled against 2.6 headers. That explains!
In other words, time to recompile glibc against the proper headers.
However, that task is a bit too cumbersome to post here. Long story short: it took me half the day to meddle with the glibc.Slackbuild script (and get the right kernel headers installed, etc) and I finally have a new glibc which works.

So, if you’re looking for a quick fix: use the LD_PRELOAD trick. For the more daring amongst you: upgrade your glibc — but beware that this is a DANGEROUS thing to do since it will break many things. Of course you could also upgrade to Slackware 13 and be done with it

Anyway, Teamspeak 3 has a much better view of the world. They offer a -free- personal (that means non commercial!) non-profit license. This means if you’re a guild you can obtain a license
from them for free over here which allows you to host your own Teamspeak 3 server with 10 virtual servers and 512 slots. That’s more like it!
And if you ARE commercial, their licenses are well defined and very affordable. For instance a 1 year license for 25 slots is only $25. Compare that to Ventrilo 2 providers that ask you E10,- per month. Ha.
Oh, did I mention that they DO have a linux client? And windows and mac of course…. including the 64 bit versions. Lovely

However, as it’s still in beta I run into some problems every now and then. Today I was asked to upgade the b12 server to the latest. So I tried.
Result:

…. welcome back my friend…. BOOST …. always the fucking same with that piece of rubbish.
However, to be fair this could very well be a “learn to code” problem by teamspeak, but still… it’s always boost the brings the curses.
So what is it complaining now? I don’t have epoll? Seriously? Let’s see about that.

So that’s not it.
The forum has this thread suggesting it might be glibc that’s too old.
However, this particular slackware 11 server has glibc version 2.3.6, which should be old enough (according to that forum thread at least). Just in case it’s not I’ll try upgrading that later.
In the meanwhile I created a thread on this problem on the forums, let’s see what they suggest. I’ll put updates here.

Interesting. Suddenly I reminded myself of some Slackware updates that probably installed a new version of boost yesterday, replacing my own version.

Oh well, since it seems to be the libtorrent part that’s bugging, I might as well upgrade it:

(or you could have used slackbuild.pl, it’s easier )

After upgrading the package, deluge starts again. Wheee.

Oh. Boost….. that time of the month. If there’s one piece of trash I’ve run into very often on my compilation expeditions…. it’s boost. What a cancer piece of trash that is. You wouldn’t believe the amount of cursing I’ve gone through on my trails through “build from source” land because of boost. It never works, and when it does it’s limping on. They should have called it “blast” instead.
These days boost is in the official slackware repositories. You’d think that would help, since I can’t mess up the paths etc anymore. (compiling boost is another disaster btw, don’t go there unless you like torture). But noo, as usual the programs that use boost (“because we can’t code ™”, or at least, that’s what I think) are so good at coding stuff themselves that they fail the autoconf for it as well. Prutsers. Well, to be honest, if they can’t code it themselves it’s probably smart to use a library that handles it for them….. but boost? :/

Anyway, back to qBitTorrent. Actually, it’s libtorrent-rasterbar that’s failing. Attempt 1, configure with only a prefix and no other options:

WHat?! Do you ahve Boost::System? Yes. I mean no!
… seriously, who comes up with this shit….
So we dig into config.log and find:

Or in other words: nothing we didn’t already know. FUCK.
Time for a trace.

…. /usr/lib? Says who? Not me, that’s for sure. idiots.
In fact, I’m quite sure that it’s in /usr/lib64.

Jup, as expected. Boost is kanker. Since boost doesn’t have the usual pkgconfig issues, we can only conclude that the reason is that either this configure.in was written by a moron, or that
boost supplies invalid tests for finding itself through the autoconf system. I suspect the latter, but that’s just me

In this case the solution is simple, since the configure script has an override option. Wonder why… maybe they ran into boost idiocies before?
The solution:

This runs through configure, it finds the boost garbage and runs through. And guess what? It even compiles!

The gist of this rant: autoconf is pretty useless if you make assumptions that autoconf is supposed to detect. If you write software, don’t assume this stuff, try to detect it.
Also: when it fails, give me an error message that is useful, not some generic error code. “Library not found” vs “library not found because libblabla.so doesn’t exist in /usr/lib”.

About qbittorrent: it’s a cute little torrent client for linux. Especially if you like faily lightweight stuff that does has a gui. The thing I like about those lightweight clients: they’re fast.
This one even has an RSS reader these days…. cute.
Here’s a screenie:

qbittorrent v1.5.0

So qBittorrent: keep up the good work, and get rid of boost