libIlmThread.so uses pthread functions but does not link against -lpthread. $ readelf -s /usr/lib/libIlmThread.so | grep pthread 12: 0000000000000000 0 FUNC GLOBAL DEFAULT UND pthread_mutex_init@GLIBC_2.2.5 (5) 20: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND pthread_create 27: 0000000000000000 0 NOTYPE WEAK DEFAULT UND pthread_cancel 34: 0000000000000000 0 FUNC GLOBAL DEFAULT UND pthread_mutex_lock@GLIBC_2.2.5 (5) 37: 0000000000000000 0 FUNC GLOBAL DEFAULT UND pthread_mutex_destroy@GLIBC_2.2.5 (5) 41: 0000000000000000 0 FUNC GLOBAL DEFAULT UND pthread_mutex_unlock@GLIBC_2.2.5 (5) 43: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND pthread_join $ readelf -d /usr/lib/libIlmThread.so Dynamic section at offset 0x5da0 contains 27 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libIex.so.10] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x000000000000000e (SONAME) Library soname: [libIlmThread.so.10] [...] media-libs/ilmbase-1.0.2 has a patch for this (files/ilmbase-1.0.0-asneeded.patch), but it was not included in the 2.0.0 ebuild. Reproducible: Always Steps to Reproduce: 1. emerge =media-libs/ilmbase-2.0.0 2. USE=openexr emerge media-gfx/nvidia-texture-tools Actual Results: [...] /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -pipe -O2 -march=amdfam10 -ggdb -pipe -Wl,-O1 -Wl,--as-needed CMakeFiles/filtertest.dir/tests/filtertest.cpp.o -o filtertest -rdynamic ../nvcore/libnvcore.so ../nvmath/libnvmath.so ../nvimage/libnvimage.so ../nvmath/libnvmath.so ../nvcore/libnvcore.so -ldl -lpng -lz -ljpeg -ltiff -lImath -lIlmImf -lIex -lHalf -lIlmThread -lz -ljpeg -ltiff -lImath -lIlmImf -lIex -lHalf -lIlmThread ../nvcore/poshlib/libposh.a -Wl,-rpath,/var/tmp/portage/media-gfx/nvidia-texture-tools-2.0.8-r1/work/nvidia-texture-tools-2.0.8_build/src/nvcore:/var/tmp/portage/media-gfx/nvidia-texture-tools-2.0.8-r1/work/nvidia-texture-tools-2.0.8_build/src/nvmath:/var/tmp/portage/media-gfx/nvidia-texture-tools-2.0.8-r1/work/nvidia-texture-tools-2.0.8_build/src/nvimage /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libIlmThread.so: undefined reference to `sem_init' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libIlmThread.so: undefined reference to `sem_destroy' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libIlmThread.so: undefined reference to `pthread_create' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libIlmThread.so: undefined reference to `sem_post' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libIlmThread.so: undefined reference to `sem_trywait' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libIlmThread.so: undefined reference to `sem_getvalue' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libIlmThread.so: undefined reference to `sem_wait' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libIlmThread.so: undefined reference to `pthread_join' Expected Results: :) $ emerge --info '=media-gfx/nvidia-texture-tools-2.0.8-r1' Portage 2.2.0_alpha168 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.16.0, 3.6.11-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.6.11-gentoo-x86_64-AMD_Phenom-tm-_9750_Quad-Core_Processor-with-gentoo-2.2 KiB Mem: 8181272 total, 150892 free KiB Swap: 8316924 total, 8316924 free Timestamp of tree: Wed, 20 Mar 2013 14:30:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.3-r3, 3.2.3-r2 dev-util/cmake: 2.8.10.2-r2::kde dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.11.6, 1.13.1 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.3.6-r1, 4.4.7, 4.5.4, 4.6.3, 4.7.2-r1, 4.8.0_pre9999::toolchain sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.8 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo local-repo kde toolchain hasufell gamerlay games arx-libertatis Installed sets: @kdeadmin-4.10, @kdeartwork-4.10, @kdebase-4.10, @kdeedu-4.10, @kdegames-4.10, @kdegraphics-4.10, @kdenetwork-4.10, @kdeutils-4.10, @system ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -O2 -march=amdfam10 -ggdb -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.0/conf /usr/share/polkit-1/actions /usr/share/themes/oxygen-gtk/gtk-3.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -O2 -march=amdfam10 -ggdb -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LC_ALL="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS=" -j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /var/lib/layman/kde /var/lib/layman/toolchain /var/lib/layman/hasufell /var/lib/layman/gamerlay /var/lib/layman/games /home/dscharrer/pro/gentoo" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X X11 acl alsa amd64 bash-completion berkdb bzip2 cli consolekit cracklib crypt cxx dbus dri fortran gdbm gpm iconv ipv6 j2k jpeg2k kde kde4 lm_sensors mmx mmxext modules mudflap multilib ncurses nls nptl openexr opengl openmp pam pch pcre pgo png poliicykit qt qt4 readline sdl semantic-desktop session sse sse2 sse3 ssl ssse3 tcpd threads truetype udev unicode v4l v4l2 x11 xgl xv zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="krita" CAMERAS="canon directory ptp2 template" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" PHP_TARGETS="php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="arm i386 x86_64" QEMU_USER_TARGETS="arm i386 x86_64" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="hp*" USERLAND="GNU" VIDEO_CARDS="fglrx" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= media-gfx/nvidia-texture-tools-2.0.8-r1 was built with the following: USE="(multilib) openexr -cg -cuda -glew -glut" $ emerge -pqv '=media-gfx/nvidia-texture-tools-2.0.8-r1' [ebuild R ] media-gfx/nvidia-texture-tools-2.0.8-r1 USE="openexr -cg -cuda -glew -glut"
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 ***
