Re: OpenEXR 1.6.1 build problem (Linux): "configure: error: Could not compile IlmBase test program"

Frank Thommen <[email protected]> Wed, 02 Sep 2009 18:28:24 +0200
Newsgroups gmane.comp.video.openexr.user
Organization Structures IT Management, EMBL Heidelberg
Message-ID <[email protected]>
Hi Ger,

sorry for not keeping up, I was busy with other projects...


Ger Hobbelt wrote:
> hmmmm... haven't built EXR on Linux for a long time myself - let's see...
> 
> when you run the ./configure for IlmBase, it reports back what's
> seeing and going to use. A part of output concerns threading; here's
> the snippet from my 64-bit Ubuntu dev box; the point is that there
> should be at least one 'yes' in this section ;-)
> 
> ---snip---
> checking for the pthreads library -lpthreads... no
> checking whether pthreads work without any flags... no
> checking whether pthreads work with -Kthread... no
> checking whether pthreads work with -kthread... no
> checking for the pthreads library -llthread... no
> checking whether pthreads work with -pthread... yes
> checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
> checking if more special flags are required for pthreads... no
> ---snip---


In my ./configure ouput for ilmbase (1.0.1) I have exactly the same 
lines as you listed above.



> I'm curious what your platform is saying there; before we dive any
> deeper this 'detection code' in the configure script should give us an
> idea where to poke next.

After some additional searching I found this page: 
http://www.mail-archive.com/[email protected]/msg00690.html (I 
hadn't searched in the devel list previously).  It describes exactly my 
problem and after adding '-lrt -fPIC' to gcc and g++, openexr compiled 
and built w/o error messages.



>> I have no software development knowledge and therefore these error messages
>> are somehow cryptic to me.  But I see, that libIlmThread.so does not refer
>> (link?) to pthread.so at all:
> 
> You're doing fine for a non-dev. Keep it up ;-)
> 
>> openexr-1.6 > ldd ../../lib/libIlmThread.so
>>        libIex.so.6 => /usr/struct/pack/openexr-1.6/lib/libIex.so.6
>> (0x00002ae626943000)
>>        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002ae626b60000)
>>        libm.so.6 => /lib64/libm.so.6 (0x00002ae626e80000)
>>        libc.so.6 => /lib64/libc.so.6 (0x00002ae627104000)
>>        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002ae62745a000)
>>        /lib64/ld-linux-x86-64.so.2 (0x00000031e8c00000)
>> openexr-1.6 >
>>
>>
>> Could that be the problem and is there a way to fix it?
> 
> That's the issue; the tough question is two-part: (1) where did the
> process screw up exactly --> (2) once we know the 'where' in more
> detail, what can we do to kick it into cooperating.
> 
> 
> ... oh dang. dang. dang. I forgot. Had this issue already /several/
> times in a row with other folks on Linux (it's due to the Linux
> package installer systems being geared a bit too much to 'using' IMO;
> creating a bit of a bother when 'users' take the obvious step thinking
> "heck, what's so hard in typing './configure' and 'make install'
> anyway?" And then they get a nasty surprise they should _not_ have
> got. I got a few nasty surprises myself when I returned to this
> platform after several years. But I digress.)
> 
> The thing to check:
> 
> your system has a 'package installer' of some sort where you select
> the 'packages' you want installed on your system, e.g. 'pthreads',
> 'gcc compiler', 'open office', etc.etc.
> Now here's the nasty bit: I bet myself a bottle of good single malt
> you've got 'pthreads' or 'libpthreads' or whatever they'll call it in
> your package manager (e.g. on Ubuntu: System>Administration>Synaptic
> Package Manager) checked as 'already installed' in that manager
> (that's why you could find that libpthreads.so loadable library) but
> you (and this is my bet) do /not/ have the 'libpthreads-dev' package
> installed /as well/ (should be called the same with ' dev' or '-dev'
> something appended to the name). Maybe it even comes with a
> description where it says that the 'dev' package will install the
> 'header files'. Tick that one and install, because /that's/ what
> ./configure is looking for too: to build a piece of software which
> depends on a library of any sort, in Linux nowadays you need both the
> 'libraryXYZ' _plus_ the 'libraryXYZ-dev' packages installed or you get
> a situation very much like this one: everything looks good, meanwhile
> nothing builds, linker errors galore and you're left pulling your
> hair.
> 
> If that 'pthreads-dev' package was not yet installed, and now that it
> is, rerun all ./configure scripts (IlmBase, OpenEXR, etc.) and 'make',
> 'make check' and 'make install' commands like you did before, so that
> the newfound pthreads 'header files' can be detected by the configure
> scripts and alter the OpenEXR build instructions accordingly.
> 
> 
> ... do I win my bet or did I loose? ;-)


I'm sorry, but you lost the bet :-)).  In CentOS, libpthread comes with 
the glibc and glibc-devel packages, but the glibc-headers with all 
headerfiles was also installed.  So I think it was really the missing 
options and the old/not updated autoconf script that comes with OpenEXR. 
  Don't be sad, there will other bets to win in the future :-).

For the single malt: An old Cragganmore would be perfect. Yummy!


Thanks a lot for your help.  Now I'll go on and try to solve the Blender 
build error messages :-(

     frank