Summary: | media-libs/ilmbase-2.0.1-r1: libIlmThread.so doesn't link to libpthread | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Cabrera <robcab666> |
Component: | [OLD] Library | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | amade, ansla80, base-system, bircoph, blackst0ne.ru, email, I.zaufi, ikelos, johannes.hirte, kredba, stefantalpalaru, timtaler, vmatare+gbug, waltercool |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=499028 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 378027 | ||
Attachments: |
build.log
ilmbase-2.0.1-pthreads.patch |
Description
Robert Cabrera
2014-01-02 22:42:47 UTC
Created attachment 366798 [details]
build.log
Attached build.log
Seems to be a parallel-make problem. Restricting MAKEOPTS to -j1 works for me. Unfortunately, setting MAKEOPTS="-j1" has no effect for me. It was the first thing I tried while troubleshooting. I just tried again with the same result. This might be related to the way ilmbase was build. I found the following oddity in ilmbase's pkgconfig file: Libs: -L${libdir} -lImath -lHalf -lIex -lIexMath -lIlmThread -pthread which when changed to: Libs: -L${libdir} -lImath -lHalf -lIex -lIexMath -lIlmThread -lpthread allowed openexr to compile without problem. Note that the -pthread option was already present in the pkgconfig file in the cflags line: Cflags: -pthread -I${OpenEXR_includedir} The problem is, I can't determine how that -pthread at the end of that line is getting there. It comes from ${PTHREAD_LIBS} in the configure script, but even when I regenerated the configure using eautoreconf, it still put the same value there... Does anyone know autotools well enough to help me figure out where ${PTHREAD_LIBS} is populated from? Created attachment 367024 [details, diff]
ilmbase-2.0.1-pthreads.patch
So, I tracked down the choice of -pthread over -lpthread to the m4/threads.m4 file (which is why autoreconf wasn't producing different results), so they package their own macros for figuring out what PTHREAD_LIBS should be. This is the most trivial patch I could produce to push -lpthread higher in the priority list, which works, however I don't know enough about autoconf or pthreads to know why any of this is even a problem, so I've no idea whether this is the right fix or not. Ideally, someone with more knowledge on the area could look further, if there were more than just ilmbase that this affected.
After applying the patch, eautoreconf has to be run as well...
I get the same error with or without the above patch. Chris, could you please check your /usr/lib{64,32}/pkgconfig/IlmBase.pc files to check whether they contain -lpthread, or just -pthread? If they contained -pthread could you please check that you ran eautoreconf as well as applying the patch on ilmbase, and then after successfully compiling ilmbase, try recompiling openexr? Ok it worked. Thanks Same problem here with ilmbase-2.0.1-r1 and openxr-2.0.1-r1. Patch (with eautoreconf) works fine. Thanks. It'll be great to see this in tree. *** Bug 497612 has been marked as a duplicate of this bug. *** patch works for me on amd64 and x86, lets get this patch for media-libs/ilmbase in tree. Comment on attachment 367024 [details, diff] ilmbase-2.0.1-pthreads.patch >diff --git a/m4/threads.m4 b/m4/threads.m4 >index 2213bb8..61ef252 100644 >--- a/m4/threads.m4 >+++ b/m4/threads.m4 >@@ -87,7 +87,7 @@ fi > # which indicates that we try without any flags at all, and "pthread-config" > # which is a program returning the flags for the Pth emulation library. > >-acx_pthread_flags="pthreads none -Kthread -kthread lthread -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-config" >+acx_pthread_flags="pthreads none -Kthread -kthread lthread pthread -pthread -pthreads -mthreads --thread-safe -mt pthread-config" This is clearly wrong. This is a common autoconf macro, and the choices are in that order for a good reason (which I don't know but still). Well, it's clearly a problem of ilmbase. libIlmThread should be linked to pthread but it doesn't get that linking for some reason. As a result, more strict linker refuses to link against incomplete libIlmThread. (In reply to Michał Górny from comment #13) > Well, it's clearly a problem of ilmbase. not quite ilmbase, but mostly libtool... http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/11704 CC base-system@ for Comment #14 *** Bug 498296 has been marked as a duplicate of this bug. *** See please a list of maybe affected too packages: find /usr/lib64/pkgconfig -type f -exec grep -H pthread {} \; |grep -v lpth| grep -v Cfla : /usr/lib64/pkgconfig/fuse.pc:Libs: -L${libdir} -lfuse -pthread /usr/lib64/pkgconfig/libxine.pc:Libs.private: -lz -lresolv -lnsl -pthread -lrt /usr/lib64/pkgconfig/gmodule-2.0.pc:Libs: -L${libdir} -Wl,--export-dynamic -lgmodule-2.0 -pthread /usr/lib64/pkgconfig/gmodule-export-2.0.pc:Libs: -L${libdir} -Wl,--export-dynamic -lgmodule-2.0 -pthread /usr/lib64/pkgconfig/plplotd-wxwidgets.pc:Libs: -L${libdir} -lplplotwxwidgetsd -lplplotd -lplplotcxxd -pthread -Wl,--as-needed -Wl,-O2 -Wl,-flto=4 -flto=4 -fuse-linker-plugin -O2 -ggdb -pipe -march=native -mtune=native -fno-lto -fno-use-linker-plugin -lwx_baseu-2.8 -lwx_gtk2u_core-2.8 -lagg -laggfontfreetype -lfreetype /usr/lib64/pkgconfig/libwebpdecoder.pc:Libs.private: -lm -pthread /usr/lib64/pkgconfig/libpcre.pc:Libs.private: -pthread /usr/lib64/pkgconfig/libpcrecpp.pc:Libs.private: -pthread /usr/lib64/pkgconfig/gmodule-no-export-2.0.pc:Libs: -L${libdir} -lgmodule-2.0 -pthread /usr/lib64/pkgconfig/liblzma.pc:Libs.private: -pthread /usr/lib64/pkgconfig/gthread-2.0.pc:Libs: -L${libdir} -lgthread-2.0 -pthread /usr/lib64/pkgconfig/glib-2.0.pc:Libs.private: -pthread /usr/lib64/pkgconfig/nice.pc:Libs: -L${libdir} -lnice -lgthread-2.0 -pthread -lgio-2.0 -lgobject-2.0 -lglib-2.0 /usr/lib64/pkgconfig/libusb-1.0.pc:Libs.private: -lrt -pthread /usr/lib64/pkgconfig/libwebp.pc:Libs.private: -lm -pthread /usr/lib64/pkgconfig/libpcreposix.pc:Libs.private: -pthread That is probably why I can't link some application when I try them with LTO. I have binutils-2.24 and gcc-4.8.x and I can't reproduce this bug. I first re-emerged ilmbase, just to be sure. It doesn't link against -pthread, which is expected as that information is coming from the pkg-config file which is enough: $ pkg-config --cflags IlmBase -pthread -I/usr/include/OpenEXR Then I emerged openexr succesfully. *** This bug has been marked as a duplicate of bug 462494 *** bug 499028 was opened for libtool, yet I'm not sure it's the right thing to do :-/ why it works for some, and others not? what version of libtool are those people with failures using? (In reply to Samuli Suominen from comment #20) > bug 499028 was opened for libtool, yet I'm not sure it's the right thing to > do :-/ > why it works for some, and others not? what version of libtool are those > people with failures using? Forgot to clarify. Working here with sys-devel/libtool-2.4.2 without adding any patch. And are the people with failures using what `ld`? gold or not? $ ld -v GNU ld (GNU Binutils) 2.24 (In reply to Samuli Suominen from comment #22) > And are the people with failures using what `ld`? gold or not? > > $ ld -v > GNU ld (GNU Binutils) 2.24 Mine is a new install on Jan 14. openexr now successfully builds after updating binutils from 2.24-r1 to 2.24-r2. libtool has only ever been on 1 version on this machine - 2.4.2 USE has not changed. [I] sys-devel/binutils Available versions: (~)2.19.1-r1 2.20.1-r1 2.21.1-r1 2.22-r1 **2.22.52.0.4 (~)2.22.90 (~)2.23 2.23.1 2.23.2 **2.23.51.0.1 **2.23.51.0.2 **2.23.51.0.3 **2.23.51.0.5 **2.23.51.0.6 **2.23.51.0.7 **2.23.51.0.8 **2.23.51.0.9 **2.23.52.0.1 **2.23.52.0.2 (~)2.24-r2{tbz2} **2.24.51.0.1 **2.24.51.0.2 **9999 {cxx multislot multitarget nls static-libs test vanilla zlib} Installed versions: 2.24-r2{tbz2}(13:01:02 01/20/14)(cxx nls zlib -multislot -multitarget -static-libs -test -vanilla) Homepage: http://sourceware.org/binutils/ Description: Tools necessary to build programs This information is included in emerge --info, and it looks like the OP was using the same ld. I was probably using the same as well, not sure about the version but definatly not gold. How about LDFLAGS="-Wl,-O1 -Wl,--as-needed"? This is what both the OP and I have in make.conf (In reply to Andrei Slavoiu from comment #24) > This information is included in emerge --info, and it looks like the OP was > using the same ld. I was probably using the same as well, not sure about the > version but definatly not gold. > > How about LDFLAGS="-Wl,-O1 -Wl,--as-needed"? This is what both the OP and I > have in make.conf '--as-needed' is default in Gentoo's LDFLAGS http://permalink.gmane.org/gmane.comp.gnu.libtool.patches/11704 doesn't apply anymore to libtool 2.4+ i'm not convinced it's buggy at all yet, anyone hitting this, make sure to update sys-devel/libtool I can no longer recreate this as of sys-devel/binutils-2.24-r2, libtool has not changed since the problem disappeared. *** Bug 499462 has been marked as a duplicate of this bug. *** bug 499462, Comment #6 hints upgrading binutils to 2.24-r2 fixes things |