| Summary: | djvu-3.5.17: fix unresolved symbols in libdjvulibre.so (--as-needed) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | TGL <tom.gl> |
| Component: | Current packages | Assignee: | Text-Markup Team (OBSOLETE) <text-markup+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cems, dberkholz, flameeyes, genstef, ikelos |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 129413 | ||
| Attachments: |
djvu-3.5.17-libpthread.patch
files/djvulibre-3.5.17-pthread-flag.patch |
||
Created attachment 86292 [details, diff]
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 attachment 86422 [details, diff]
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? |
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.