[ptx] error compiling hugin on x86_64 (fedora fc4)

[Michael Galloway]

still does not configure for me. i updated from cvs a few minutes ago and still i get:

checking boost version... 1.31
checking Boost headers files presence... /usr/include
checking Boost libraries presence... /usr/lib
checking for boost... yes
checking boost/thread/thread.hpp usability... no
checking boost/thread/thread.hpp presence... no
checking for boost/thread/thread.hpp... no
checking for boost thread library... no
checking for boost_thread library variant presence... no
configure: error:
        the boost thread library must be installed on your system
        but configure could not find it. Use --with-boost to
        specify the location of the boost library and
        --with-boost-version to specify your version


with:

lance:/tmp/hugin # rpm -qa | grep boost
boost-devel-1.33.0-0.pm.0
boost-1.33.0-0.pm.0
lance:/tmp/hugin # ldconfig -p | grep libboost_thread
        libboost_thread-gcc-mt-1_33.so.1.33.0 (libc6,x86-64) => /usr/lib64/libboost_thread-gcc-mt-1_33.so.1.33.0
        libboost_thread-gcc-mt-1_33.so (libc6,x86-64) => /usr/lib64/libboost_thread-gcc-mt-1_33.so
lance:/tmp/hugin #

is there pehaps a problem with the suse boost build? thanks!

--- michael

On Fri, Feb 10, 2006 at 09:11:02AM +0100, Pablo d'Angelo wrote:
> Hi all,
> 
> > I get exactly the same ./configure output as Hal:
> > 
> >> checking for boost thread library... yes
> >> checking for boost_thread library variant presence... no
> > 
> > I also have these files present:
> > 
> >  /usr/lib64/libboost_thread.a
> >  /usr/lib64/libboost_thread.so -> libboost_thread.so.1.32.0
> >  /usr/lib64/libboost_thread.so.1 -> libboost_thread.so.1.32.0
> >  /usr/lib64/libboost_thread.so.1.32.0
> > 
> > Ah, if I create a symlink into /usr/lib/ then ./configure finds the
> > library:
> > 
> >  checking for boost_thread library variant presence...
> >  /usr/lib/libboost_thread.so
> > 
> > ...obviously not an ideal solution.
> 
> Hmm, I didn't detect this, since my distribution (ubuntu) places all 64 bit
> libs in libs and the 32 bit ones (if installed...) in lib32.
> 
> The autoconf macro for the boost detection is not trivial, since boost libs
> sometimes encode the compiler name inside the library. But I suspect that a
> more robust version could be written. However, I don't know enought of
> autoconf/m4 to do this.
> 
> As a workaround, the lib64 paths are now also searched for the boost
> library. I hope this should fixes the compile problems, as long as no
> different build are installed in lib and lib64.
> 
> ciao
>   Pablo
>