Summary: | =media-libs/ilmbase-2.1.0 - libIlmThread.so: undefined reference to sem_init or pthread_join (Upgrade sys-devel/binutils to 2.24-r2 for working linker!) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Daniel Scharrer <daniel> |
Component: | [OLD] Library | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | ansla80, dschridde+gentoobugs, hasufell, heiko.baums, jfostiguy, kredba, robcab666, silvio.gerli, ssuominen |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
ilmbase-2.0.0-asneeded.patch |
Description
Daniel Scharrer
2013-03-20 15:13:31 UTC
Created attachment 342718 [details]
build.log
mh, maybe we should make a snapshot and update the package upstream does not work at nvidia anymore, so there is no release schedule, but he keeps updating the repository +*nvidia-texture-tools-2.0.8-r2 (20 Mar 2013) + + 20 Mar 2013; Julian Ospald <hasufell@gentoo.org> + +nvidia-texture-tools-2.0.8-r2.ebuild, + +files/nvidia-texture-tools-2.0.8-openexr.patch: + use pkg-config for openexr detection wrt #462494 I still think we should apply the as-needed patch from ilmbase-1.0.2 to 2.0.0 which also fixes the problem. It's not so nice to rely on other projects to use pkg-config. Created attachment 342792 [details, diff]
ilmbase-2.0.0-asneeded.patch
I can't reproduce here: USE="openexr" emerge -av nvidia-texture-tools works fine here with, or without this patch: + 21 Mar 2013; Samuli Suominen <ssuominen@gentoo.org> ilmbase-2.0.0.ebuild, + +files/ilmbase-2.0.0-underlinking.patch: + Link libIlmThread against $(PTHREAD_LIBS) from m4/threads.m4 wrt #462494 by + Julian Ospald and Daniel Scharrer Even after seeing -lpthread in the linker line in final link of libIlmThread, the library doesn't link against it: $ objdump -p /usr/lib64/libIlmThread.so.10.0.0|grep NEEDED NEEDED libIex.so.10 NEEDED libstdc++.so.6 NEEDED libc.so.6 NEEDED libgcc_s.so.1 So I'm not sure howto reproduce this bug, but what I've been told by hasufell at IRC and what I'm reading here, it's still the correct thing to do so... It's in Portage I think this issue is back: configure:5510: checking for Vigra import/export-library configure:5524: x86_64-pc-linux-gnu-g++ -o conftest -pipe -O2 -march=athlon64-sse3 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu conftest.cpp -lvigraimpex -llcms2 -ltiff -lpng -ljpeg -lz -lgsl -lgslcblas -lm >&5 /usr/lib64/libIlmThread.so.10: undefined reference to `pthread_create' /usr/lib64/libIlmThread.so.10: undefined reference to `sem_wait' /usr/lib64/libIlmThread.so.10: undefined reference to `sem_init' /usr/lib64/libIlmThread.so.10: undefined reference to `sem_destroy' /usr/lib64/libIlmThread.so.10: undefined reference to `sem_getvalue' /usr/lib64/libIlmThread.so.10: undefined reference to `sem_post' /usr/lib64/libIlmThread.so.10: undefined reference to `sem_trywait' /usr/lib64/libIlmThread.so.10: undefined reference to `pthread_join' collect2: error: ld returned 1 exit status When building media-gfx/enblend-4.1.1 and with: $ q file -v /usr/lib64/libIlmThread.so.10 media-libs/ilmbase-2.0.0 (/usr/lib64/libIlmThread.so.10) open a new bug and add this one to "See Also" (In reply to Julian Ospald (hasufell) from comment #7) > open a new bug and add this one to "See Also" bug #476836 *** Bug 496810 has been marked as a duplicate of this bug. *** *** Bug 476836 has been marked as a duplicate of this bug. *** when emerging openexr-2.1.0 after ilmbase-2.1.0, I see (during econf): using pkg-config to set ILMBASE_CXXFLAGS and ILMBASE_LDFLAGS: ILMBASE_CXXFLAGS = -pthread -I/usr/include/OpenEXR ILMBASE_LDFLAGS = ILMBASE_LIBS = -lImath -lHalf -lIex -lIexMath -lIlmThread -pthread and then succesful emerge *** Bug 499300 has been marked as a duplicate of this bug. *** I did an `emerge -C openexr ilmbase`. Then `emerge -uDN world` first installed ilmbase again without any problems, but failed to build openexr afterwards. openexr-2.0.1-r1 builds successfully. So if bug #499300 is really a duplicate of this bug, then this bug isn't fixed and needs to be reopened. Or the other bug needs to be reopened. (In reply to Heiko Baums from comment #13) > Then `emerge -uDN world` first installed ilmbase again without any problems, > but failed to build openexr afterwards. I should add that it first installed ilmbase-2.1.0 and then tried to install openexr-2.1.0. I can confirm that the bug is *not* fixed. The results are the same for me as reported in comments 13 & 14. See Comment #11. Is that not what you see during ./configure (src_configure, econf) of openexr? -pthread is there, and the build is succesful. Using libtool-2.4.2 and binutils-2.24. We already guessed around at bug 496810 for the possible reasons, to no avail. I'm not convinced at all this is a bug in openexr or ilmbase as pkg-config files are proper and provide necessary information to make this work. What makes your system(s) so special it doesn't compile? Give me that answer and we can finally work on the solution for the first time. (In reply to Samuli Suominen from comment #16) > What makes your system(s) so special it doesn't compile? Give me that answer > and we can finally work on the solution for the first time. Nothing makes my system special, and the error messages do look like it is a bug in openexr-2.1.0 or ilmbase-2.1.0, particularly because openexr-2.0.1-r1 can be built against ilmbase. My build.log can be found in bug #499300. I'm not sure how 2.0.1-r1, which uses the Comment #4 patch, makes things working again since it doesn't eventually link against -lpthread despite being in the _LIBADD: how about this output from system where 2.0.1-r1 is built? $ qlist ilmbase | grep lib64.*so | xargs objdump -p|grep NEEDED.*thread $ ld -v $ emerge --info |grep LDFLAGS returns nothing here, but it should list "NEEDED -lpthread" if the patch attached here makes any difference... (In reply to Samuli Suominen from comment #18) > 2.0.1-r1 ignore that version, confused w/ openexr (In reply to Heiko Baums from comment #17) > (In reply to Samuli Suominen from comment #16) > > What makes your system(s) so special it doesn't compile? Give me that answer > > and we can finally work on the solution for the first time. > > Nothing makes my system special, and the error messages do look like it is a > bug in openexr-2.1.0 or ilmbase-2.1.0, particularly because openexr-2.0.1-r1 > can be built against ilmbase. > > My build.log can be found in bug #499300. eh. openexr-2.0.1-r1 is about identical with openexr-2.1.0, neither has any patch to workaround the issue. the build-system regarding configure.in and Makefile.am's are also identical. (In reply to Samuli Suominen from comment #20) > eh. openexr-2.0.1-r1 is about identical with openexr-2.1.0, neither has any > patch to workaround the issue. the build-system regarding configure.in and > Makefile.am's are also identical. And because they are identical they have different version numbers? And because they are identical the one can be built and the other version can't? Think again, and probably read the build.log and my other bug report. There you can read, why it fails to build. The compiler gives, indeed, some hints what's wrong with the code, either the code of ilmbase-2.1.0 or the one of openexr-2.1.0. But I don't know both of them, I've just got them installed as dependencies. Have you thought about that being an upstream bug? After each rebuild of packages I reported before (and maybe in another bug) I have to fix pc files. In Libs and Libs.private it has -pthred instead of -lpthread. In Cflags there is always fine -pthread. Without Ilmbase.pc file fixed openexr does not link. (It was pcre, lzma, glib-2.0, gthread-2.0, gmodule-no-export-2.0, gmodule-export-2.0, gmodule-2.0, webp, xine and libusb-1.0. any of other of 2000+ packages on my system are not affected by this.) I am still suspecting libtool but have no evidence for it :-(. It is happening with snapshot of binutils too, with gcc-4.9 trunk too. (In reply to David Kredba from comment #22) > After each rebuild of packages I reported before (and maybe in another bug) > I have to fix pc files. > In Libs and Libs.private it has -pthred instead of -lpthread. that's fine. -pthread includes -lpthread in gcc. what pkg-config are you using? i mean, someone with this failure. $ qlist -Iv pkgconf dev-util/pkgconfig-0.28 (In reply to Samuli Suominen from comment #24) > what pkg-config are you using? i mean, someone with this failure. > > $ qlist -Iv pkgconf > dev-util/pkgconfig-0.28 I am using pkgconfig-0.28. (In reply to Samuli Suominen from comment #23) > (In reply to David Kredba from comment #22) > > After each rebuild of packages I reported before (and maybe in another bug) > > I have to fix pc files. > > In Libs and Libs.private it has -pthred instead of -lpthread. > > that's fine. -pthread includes -lpthread in gcc. OK, but my gcc plays like not until I add -l before pthread in Libs, and Libs.private. Next ebuild xxx.ebuild compile then succeeds. I have vannila alpha gcc 4.9 but with fully supported gcc-4.8.2 it fails the same way. dev-util/pkgconfig-0.28 bug 499462, Comment #6 hints upgrading binutils to 2.24-r2 fixes things same as bug 496810, Comment #27 unfortunate this took so long to track down bug should propably be marked as duplicate of bug 497976 (In reply to Samuli Suominen from comment #27) > bug 499462, Comment #6 hints upgrading binutils to 2.24-r2 fixes things > same as bug 496810, Comment #27 > unfortunate this took so long to track down > bug should propably be marked as duplicate of bug 497976 binutils is not the reason. I have installed binutils-2.24-r2 and building openexr-2.1.0 fails to build against ilmbase-2.1.0. Remember, I ran `emerge --sync` and `emerge -uDN world`. (In reply to Heiko Baums from comment #28) > (In reply to Samuli Suominen from comment #27) > > bug 499462, Comment #6 hints upgrading binutils to 2.24-r2 fixes things > > same as bug 496810, Comment #27 > > unfortunate this took so long to track down > > bug should propably be marked as duplicate of bug 497976 > > binutils is not the reason. I have installed binutils-2.24-r2 and building > openexr-2.1.0 fails to build against ilmbase-2.1.0. > > Remember, I ran `emerge --sync` and `emerge -uDN world`. did you re-emerge ilmbase with the new binutils? also, if that doesn't work, what about completely 'emerge -C ilmbase openexr' and actually rm -f'ing whatever old preserved libs files might be left and trying from a clean slate? is your ld gold (new) or bfd (normal, old)? `ld -v` will tell. (In reply to Heiko Baums from comment #21) > (In reply to Samuli Suominen from comment #20) > > eh. openexr-2.0.1-r1 is about identical with openexr-2.1.0, neither has any > > patch to workaround the issue. the build-system regarding configure.in and > > Makefile.am's are also identical. > > And because they are identical they have different version numbers? And > because they are identical the one can be built and the other version can't? > > Think again, and probably read the build.log and my other bug report. There > you can read, why it fails to build. The compiler gives, indeed, some hints > what's wrong with the code, either the code of ilmbase-2.1.0 or the one of > openexr-2.1.0. > > But I don't know both of them, I've just got them installed as dependencies. > > Have you thought about that being an upstream bug? I mean this by "identical": ssuominen@null /tmp $ diff -u ilmbase-2.0.1/configure.ac ilmbase-2.1.0/configure.ac --- ilmbase-2.0.1/configure.ac 2013-06-18 22:55:16.000000000 +0300 +++ ilmbase-2.1.0/configure.ac 2013-11-12 01:09:51.000000000 +0200 @@ -1,9 +1,9 @@ dnl Process this file with autoconf to produce a configure script. -AC_INIT(IlmBase, 2.0.1) +AC_INIT(IlmBase, 2.1.0) AC_SUBST(ILMBASE_VERSION_MAJOR, 2) -AC_SUBST(ILMBASE_VERSION_MINOR, 0) -AC_SUBST(ILMBASE_VERSION_PATCH, 1) +AC_SUBST(ILMBASE_VERSION_MINOR, 1) +AC_SUBST(ILMBASE_VERSION_PATCH, 0) AC_SUBST(ILMBASE_VERSION, ${ILMBASE_VERSION_MAJOR}.${ILMBASE_VERSION_MINOR}.${ILMBASE_VERSION_PATCH}) AC_SUBST(ILMBASE_VERSION_API, ${ILMBASE_VERSION_MAJOR}_${ILMBASE_VERSION_MINOR}) @@ -15,8 +15,8 @@ AM_MAINTAINER_MODE -LIBTOOL_CURRENT=10 -LIBTOOL_REVISION=1 +LIBTOOL_CURRENT=11 +LIBTOOL_REVISION=0 LIBTOOL_AGE=0 LIBTOOL_VERSION=$LIBTOOL_CURRENT:$LIBTOOL_REVISION:$LIBTOOL_AGE AC_SUBST(LIBTOOL_VERSION) ssuominen@null /tmp $ diff -u ilmbase-2.0.1/IlmThread/Makefile.am ilmbase-2.1.0/IlmThread/Makefile.am (In reply to Samuli Suominen from comment #29) > did you re-emerge ilmbase with the new binutils? > also, if that doesn't work, what about completely 'emerge -C ilmbase > openexr' and actually rm -f'ing whatever old preserved libs files might be > left and trying from a clean slate? > > is your ld gold (new) or bfd (normal, old)? `ld -v` will tell. Meanwhile I ran `emerge -C openexr ilmbase` again, removed openexr-2.1.0 from my package.mask and ran `emerge -uDN world` again. Now ilmbase-2.1.0 and openexr-2.1.0 have been built correctly. Maybe I indeed missed the "before" in bug 499462, Comment #6. (In reply to Samuli Suominen from comment #30) > I mean this by "identical": > > ssuominen@null /tmp $ diff -u ilmbase-2.0.1/configure.ac > ilmbase-2.1.0/configure.ac > --- ilmbase-2.0.1/configure.ac 2013-06-18 22:55:16.000000000 +0300 > +++ ilmbase-2.1.0/configure.ac 2013-11-12 01:09:51.000000000 +0200 > @@ -1,9 +1,9 @@ > dnl Process this file with autoconf to produce a configure script. > -AC_INIT(IlmBase, 2.0.1) > +AC_INIT(IlmBase, 2.1.0) > > AC_SUBST(ILMBASE_VERSION_MAJOR, 2) > -AC_SUBST(ILMBASE_VERSION_MINOR, 0) > -AC_SUBST(ILMBASE_VERSION_PATCH, 1) > +AC_SUBST(ILMBASE_VERSION_MINOR, 1) > +AC_SUBST(ILMBASE_VERSION_PATCH, 0) > > AC_SUBST(ILMBASE_VERSION, > ${ILMBASE_VERSION_MAJOR}.${ILMBASE_VERSION_MINOR}.${ILMBASE_VERSION_PATCH}) > AC_SUBST(ILMBASE_VERSION_API, > ${ILMBASE_VERSION_MAJOR}_${ILMBASE_VERSION_MINOR}) > @@ -15,8 +15,8 @@ > AM_MAINTAINER_MODE > > > -LIBTOOL_CURRENT=10 > -LIBTOOL_REVISION=1 > +LIBTOOL_CURRENT=11 > +LIBTOOL_REVISION=0 > LIBTOOL_AGE=0 > LIBTOOL_VERSION=$LIBTOOL_CURRENT:$LIBTOOL_REVISION:$LIBTOOL_AGE > AC_SUBST(LIBTOOL_VERSION) > ssuominen@null /tmp $ diff -u ilmbase-2.0.1/IlmThread/Makefile.am > ilmbase-2.1.0/IlmThread/Makefile.am Have a closer look. This is not identical. > -AC_SUBST(ILMBASE_VERSION_MINOR, 0) > -AC_SUBST(ILMBASE_VERSION_PATCH, 1) > +AC_SUBST(ILMBASE_VERSION_MINOR, 1) > +AC_SUBST(ILMBASE_VERSION_PATCH, 0) > -LIBTOOL_CURRENT=10 > -LIBTOOL_REVISION=1 > +LIBTOOL_CURRENT=11 > +LIBTOOL_REVISION=0 (In reply to Heiko Baums from comment #32) > (In reply to Samuli Suominen from comment #30) > > I mean this by "identical": > > > > ssuominen@null /tmp $ diff -u ilmbase-2.0.1/configure.ac > > ilmbase-2.1.0/configure.ac > > --- ilmbase-2.0.1/configure.ac 2013-06-18 22:55:16.000000000 +0300 > > +++ ilmbase-2.1.0/configure.ac 2013-11-12 01:09:51.000000000 +0200 > > @@ -1,9 +1,9 @@ > > dnl Process this file with autoconf to produce a configure script. > > -AC_INIT(IlmBase, 2.0.1) > > +AC_INIT(IlmBase, 2.1.0) > > > > AC_SUBST(ILMBASE_VERSION_MAJOR, 2) > > -AC_SUBST(ILMBASE_VERSION_MINOR, 0) > > -AC_SUBST(ILMBASE_VERSION_PATCH, 1) > > +AC_SUBST(ILMBASE_VERSION_MINOR, 1) > > +AC_SUBST(ILMBASE_VERSION_PATCH, 0) > > > > AC_SUBST(ILMBASE_VERSION, > > ${ILMBASE_VERSION_MAJOR}.${ILMBASE_VERSION_MINOR}.${ILMBASE_VERSION_PATCH}) > > AC_SUBST(ILMBASE_VERSION_API, > > ${ILMBASE_VERSION_MAJOR}_${ILMBASE_VERSION_MINOR}) > > @@ -15,8 +15,8 @@ > > AM_MAINTAINER_MODE > > > > > > -LIBTOOL_CURRENT=10 > > -LIBTOOL_REVISION=1 > > +LIBTOOL_CURRENT=11 > > +LIBTOOL_REVISION=0 > > LIBTOOL_AGE=0 > > LIBTOOL_VERSION=$LIBTOOL_CURRENT:$LIBTOOL_REVISION:$LIBTOOL_AGE > > AC_SUBST(LIBTOOL_VERSION) > > ssuominen@null /tmp $ diff -u ilmbase-2.0.1/IlmThread/Makefile.am > > ilmbase-2.1.0/IlmThread/Makefile.am > > Have a closer look. This is not identical. that's just nitpicking, and wrongly so, since I was just correctly pointing out there was no differences in the build systems libraries/linking/and so forth. the libtool version number has zero meaning to this bug, so in regard to this bug, it is identical for all the parts it matters. *** This bug has been marked as a duplicate of bug 497976 *** |