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

[Hal V. Engel]

On Friday 10 February 2006 12:11 am, 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

My distro (Gentoo) places the 64 bit libraries in /usr/lib64 and there is a 
link from /usr/lib to /usr/lib64.  32 bit libraries are in /usr/lib32.  

The other odd thing about my distro is that I don't have a libboost_thread.a 
or .so.  Instead I have libboost_thread-mt.a and .so.   I ended up creating a 
link from libboost_thread.so to libboost_thread-mt.so and it now builds.  But 
shouldn't the configuration find this without the link?

When I try to stitch an image I get the following error:

Error during stitching

   Precondition violation!
   RemappingPanoImage::remapimage(): image sizes not consistent
   (../../src/include/PT/RemappedPanoImage.h:398)