This library should be linked to libpthread (when USE has "qt" or "threads"):
% ldd -r /usr/lib/libdjvulibre.so
linux-gate.so.1 => (0xffffe000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7dea000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libstdc++.so.6 (0xb7d09000)
libm.so.6 => /lib/libm.so.6 (0xb7ce1000)
libc.so.6 => /lib/libc.so.6 (0xb7ba2000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libgcc_s.so.1 (0xb7b96000)
undefined symbol: pthread_create (/usr/lib/libdjvulibre.so)
undefined symbol: pthread_cancel (/usr/lib/libdjvulibre.so)
Because of this, app-text/djvu won't compile with -Wl,--as-needed (fails while linking some example programs, because unresolved symbols are forbidden with this linker flag). But even without --as-needed, i think it can be an issue at runtime too (in the case a program linked to libdjvulibre but not to libpthread).
The cause of this problem is a bad interaction beetween an autoconf macro, libtool (1.5.22 here), and gcc (4.1 here). In short:
- AC_PATH_PTHREAD (see config/acinclude.m4) detects that adding "-pthread" to CFLAGS is enough to compile with threads support.
- when linking libdjvu.so, libtool passes this flag to gcc. But it triggers "-nostdlib".
- despite the "-pthread" option, gcc doesn't add "-lpthread" to the linker args when the "-nostdlib" option is in use. Thus libthread is never linked.
For a better explanation, see:
An (imho) acceptable workaround would be to force usage of "-lpthread". I will attach a patch for the ebuild which does that by setting some variables which overrides the behavior of the autoconf macros.
I don't know what could be an acceptable fix for upstream though.
Created attachment 86292 [details, diff]
Hmm no that won't work as that will break on *BSD where -lpthread is different by -pthread.
The autodetection has to be fixed instead.
Note that my explanation of the workaround is not accurate: setting this variables doesn't really "force" anything, but just gives some values to try first. If "AC_TRY_LINK_FUNC(pthread_join)" fails with this values, then the macro will continue with the normal autodetection. I don't know whether it would have been the case or not on *BSD, but if it was, then this workaround would not have break things.
(In reply to comment #2)
> The autodetection has to be fixed instead.
But this macro works just fine. It comes from the autoconf library  (not the latest version, but that's minor differences), and has a well documented semantics which is well implemented. When it detects that CFLAGS=-pthread is enough on my system to link a threaded program, it is right, there's no bug.
The real problem here is libtool breaking semantics of -pthread: it is the one which forces -nostdlib for linking, while only doing half the job of readding the libs this flag will remove.
Now, i understand there's not much to do about it here, so i'm okay to try to find other better workarounds...
I will attach a first attempt patch, which makes possible to test combinations of flags/libs in the autodetection macro, and adds the "-pthread -lpthread" combination in the case of Linux/GCC. Sure, it should probably be completed with other combinations for the other systems where libtool breaks things.
Created attachment 86422 [details, diff]
A first attempt at patching the pthread macro. Should be applied in src_unpack, before running of aclocal and autoconf.
thanks, I committed this patch to Gentoo - can you please post this upstream also?