Bug 661115 - ilmbase 1.0.2 is missing -pthread at build (link time)
ilmbase 1.0.2 is missing -pthread at build (link time)
Product: Fedora
Classification: Fedora
Component: ilmbase (Show other bugs)
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
Depends On: 661333
Blocks: 661042
  Show dependency treegraph
Reported: 2010-12-07 15:00 EST by Nicolas Chauvet (kwizart)
Modified: 2010-12-17 03:25 EST (History)
1 user (show)

See Also:
Fixed In Version: ilmbase-1.0.2-2.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-12-17 03:25:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 25460 None None None Never

  None (edit)
Description Nicolas Chauvet (kwizart) 2010-12-07 15:00:59 EST
Description of problem:
libIlmThread.so.6 is missing -pthread at build (link time)

Version-Release number of selected component (if applicable):
1.0.2.fc14 and later.

How reproducible:

Steps to Reproduce:
1. build a package using ilmbase but not specially requiring -pthread directly
(like PerceptualDiff ).
Actual results:
The package FTBFS

Expected results:
It should have built

Additional info:
$ rpmlint ilmbase
ilmbase.x86_64: W: spelling-error %description -l en_US ilm -> lm, film, mil
ilmbase.x86_64: W: spelling-error %description -l en_US Imath -> Math, I math, Imamate
ilmbase.x86_64: W: spelling-error %description -l en_US Iex -> Ex, Sex, Ier
ilmbase.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libHalf.so.6.0.0 /lib64/libm.so.6
ilmbase.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libIex.so.6.0.0 /lib64/libm.so.6
ilmbase.x86_64: W: undefined-non-weak-symbol /usr/lib64/libIlmThread.so.6.0.0 sem_init
ilmbase.x86_64: W: undefined-non-weak-symbol /usr/lib64/libIlmThread.so.6.0.0 sem_destroy
ilmbase.x86_64: W: undefined-non-weak-symbol /usr/lib64/libIlmThread.so.6.0.0 pthread_create
ilmbase.x86_64: W: undefined-non-weak-symbol /usr/lib64/libIlmThread.so.6.0.0 sem_post
ilmbase.x86_64: W: undefined-non-weak-symbol /usr/lib64/libIlmThread.so.6.0.0 sem_trywait
ilmbase.x86_64: W: undefined-non-weak-symbol /usr/lib64/libIlmThread.so.6.0.0 sem_getvalue
ilmbase.x86_64: W: undefined-non-weak-symbol /usr/lib64/libIlmThread.so.6.0.0 sem_wait
ilmbase.x86_64: W: undefined-non-weak-symbol /usr/lib64/libIlmThread.so.6.0.0 pthread_join
ilmbase.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libIlmThread.so.6.0.0 /lib64/libm.so.6
1 packages and 0 specfiles checked; 0 errors, 14 warnings.

man sem_init seems to request either -lrt or -pthread, but the lastest seems better.
Comment 1 Rex Dieter 2010-12-07 16:10:03 EST
I vaguely recall fixing this awhile back (f12?), and upstreamed the patch, but maybe this is new (or it got lost).
Comment 2 Rex Dieter 2010-12-07 16:18:10 EST
In fairness here,
$ pkg-config --libs IlmBase
-pthread -lImath -lHalf -lIex -lIlmThread 

I take it the linked failure doesn't use pkg-config ?
Comment 3 Nicolas Chauvet (kwizart) 2010-12-07 16:29:32 EST
The -pthread is needed at libIlmThread.so.6 link time creation as told by rpmlint on installed pacakge.
You can remove it from the IlmBase.pc it's wrong, (but harmless).
Comment 4 Rex Dieter 2010-12-07 16:44:17 EST
OK, but arg...

I can confirm the build links the library using (on my f14/i686 box):

g++ -shared -nostdlib /usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crti.o /usr/lib/gcc/i686-redhat-linux/4.5.1/crtbeginS.o  .libs/IlmThreadPool.o .libs/IlmThread.o .libs/IlmThreadSemaphore.o .libs/IlmThreadMutex.o .libs/IlmThreadPosix.o .libs/IlmThreadSemaphorePosix.o .libs/IlmThreadSemaphorePosixCompat.o .libs/IlmThreadMutexPosix.o  -Wl,--rpath -Wl,/tmp/kde-rdieter1/ilmbase-1.0.2/Iex/.libs ../Iex/.libs/libIex.so -L/usr/lib/gcc/i686-redhat-linux/4.5.1 -L/usr/lib/gcc/i686-redhat-linux/4.5.1/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-redhat-linux/4.5.1/crtendS.o /usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crtn.o  -m32 -march=i686 -mtune=atom -pthread -pthread -Wl,-soname -Wl,libIlmThread.so.6 -o .libs/libIlmThread.so.6.0.0

(NOTE the -pthread's in there)
Yet, the resulting library still has undefined symbols. :(

Seems manually adding -lrt here makes a lib without undefined symbols, interesting.
Comment 5 Nicolas Chauvet (kwizart) 2010-12-07 16:45:38 EST
Hum, I'm wrong. -ptread is right in the Libs: field of the .pc given that semaphore.h is used from the ilmbase API.

$ grep sem /usr/include/OpenEXR/*
IlmThreadSemaphore.h://	system-dependent counting semaphores
IlmThreadSemaphore.h:    #include <semaphore.h>
IlmThreadSemaphore.h:	mutable HANDLE _semaphore;
IlmThreadSemaphore.h:	// If the platform has Posix threads but no semapohores,
IlmThreadSemaphore.h:	struct sema_t
IlmThreadSemaphore.h:	mutable sema_t _semaphore;
IlmThreadSemaphore.h:	mutable sem_t _semaphore;

But this would need to be confirmed upstream. as not every

Now about the rpmlint issue, this is an upstream bug. The downside is that preload will fail to work in the case of missing-non-weak-symbol. So that's also a runtime issue for one of the ilmbase libs and is hidden by the build time workaround. (given that not all package may use IlmThreadSemaphore.h and requires -pthread at link time).
Comment 6 Nicolas Chauvet (kwizart) 2010-12-07 16:51:16 EST
(In reply to comment #4)
> OK, but arg...
> Seems manually adding -lrt here makes a lib without undefined symbols,
> interesting.
Weird, I've expected that -lrt was deprecated nowadays...
Comment 7 Rex Dieter 2010-12-07 16:54:11 EST
seems -lpthread works too, I think that's what I used before.

then let the upstream poking commense.
Comment 8 Nicolas Chauvet (kwizart) 2010-12-07 16:59:20 EST
While we are at it. Can you add INSTALL="install -p" to prevent timestamp changes while installing headers.

Comment 9 Rex Dieter 2010-12-07 17:02:09 EST
Didn't think timestamp changes mattered much these days. ?

Regardless, if I make the suggested change (comment #7), then -pthread will get dropped from IlmBase.pc too.  maybe need both -pthread *and* explicit linkage with -lpthread when creating libIlmThread?
Comment 10 Nicolas Chauvet (kwizart) 2010-12-07 17:07:44 EST
(In reply to comment #7)
> seems -lpthread works too, I think that's what I used before.
librt is already linked to libpthread so it's just more than enought.
ldd /lib64/librt.so.1 
 linux-vdso.so.1 =>  (0x00007fff2d7ff000)
 libc.so.6 => /lib64/libc.so.6 (0x0000003299000000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003fd6600000)
 /lib64/ld-linux-x86-64.so.2 (0x0000003298c00000)

I would have expected -pthread would imply linking to the required library.
It could be a compiler issue.

About timestamp, it's more valuable information to have the last commit date of the header than the time when it was packaged I guess.
Comment 11 Rex Dieter 2010-12-08 10:18:50 EST
As pointed out on -devel list,

-pthread should have priority over -nostdlib -> CLOSED INVALID

Ie, this will affect any g++ libtool-using app/pkg generating shlibs.
Comment 12 Nicolas Chauvet (kwizart) 2010-12-08 10:44:43 EST
Yep I've read, so my understanding is either -nostdlib  have to be removed when using g++ with -pthread; or there is a need to explicitely add -lpthread
Comment 13 Fedora Update System 2010-12-08 11:18:46 EST
ilmbase-1.0.2-2.fc14 has been submitted as an update for Fedora 14.
Comment 14 Fedora Update System 2010-12-08 16:39:39 EST
ilmbase-1.0.2-2.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update ilmbase'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ilmbase-1.0.2-2.fc14
Comment 15 Fedora Update System 2010-12-17 03:25:38 EST
ilmbase-1.0.2-2.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.