Bugzilla Bug 132473

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)
        /lib/ld-linux.so.2 (0x80000000)
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:
http://lists.gnu.org/archive/html/libtool/2005-12/msg00065.html
http://gcc.gnu.org/ml/gcc-bugs/2005-12/msg01739.html

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 an attachment (id=86292) [edit]
djvu-3.5.17-libpthread.patch

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 [1] (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.

[1] http://autoconf-archive.cryp.to/acx_pthread.html

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 an attachment (id=86422) [edit]
files/djvulibre-3.5.17-pthread-flag.patch

A first attempt at patching the pthread macro. Should be applied in src_unpack,
before running of aclocal and autoconf.

work-around:
LD_PRELOAD=/usr/lib/libXt.so.6.0.0 /usr/bin/firefox

thanks, I committed this patch to Gentoo - can you please post this upstream
also?