POV-Ray : Newsgroups : povray.unix : POV-Ray 3.7.0 Linux installation, boosted : POV-Ray 3.7.0 Linux installation, boosted Server Time
16 May 2024 23:30:58 EDT (-0400)
  POV-Ray 3.7.0 Linux installation, boosted  
From: clipka
Date: 26 Oct 2009 17:55:28
Message: <4ae61ad0$1@news.povray.org>
After having used the Intel C++ compiler (icpc) to install custom 
versions of POV-Ray to my AMD64 Debian "Etch" Linux machine successfully 
on a regular basis for many months by now, I tried with the GNU C++ 
compiler the last days - to come across some stumbling blocks; as I'd 
probably have forgotten the details in a few weeks' time, I thought I'd 
share the experience while it's fresh.

Here's my setup:

- A boost_thread library is installed in /usr/lib, and boost header 
files are installed in /usr/include/boost, from a Debian package, but 
unfortunately it's version 1.33 and therefore of no use for POV-Ray 3.7.

- A full set of boost 1.37 libraries, compiled from source, is installed 
in ${install_base_dir}/boost_1_37_0/lib, and headers in 
${install_base_dir}/boost_1_37_0/include/boost.


When compiling with the Intel compiler, I essentially use the following 
commands (after inlining iccvars.sh to set up the Intel build 
environment) which build POV-Ray successfully:

./configure                    \
     --prefix="${install_dir}"  \
     --enable-static            \
     CXX=icpc                   \
     --with-boost="${install_base_dir}/boost_1_37_0" \
     --with-boost-thread="boost_thread-gcc41-mt"     \
     --disable-debug            \
     --enable-optimize          \
     COMPILED_BY="Christoph Lipka"

make check
make install

So far, so good. One thing to note is that X11 support (and therefore 
preview) is not available with this.

So how to change this to compile with the GNU compiler suite? My first 
attempt was to just change "CXX=icpc" to "CXX=gcc" - with rather 
disappointing results:

...
Libraries
---------
checking whether to link with cygwin DLL... no
checking whether to enable static linking... yes
checking for linker static flag... -static
checking for working '-static' flag... no
configure: static linking does not work, revert to dynamic linking
...
checking whether to use the ZLIB library... yes
checking for library containing zlibVersion... -lz
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for libz version >= 1.2.1... unknown
configure: error: cannot find a suitable ZLIB library
configure failed.

Closer Examination revealed the following two problems I never managed 
to find an explanation for, let alone a solution:

- With "CXX=gcc", ./configure refuses to use static linkage.

- With dynamic linkage, the runtime is unable to load the shared 
boost_thread library, at least during ./configure; as this library is 
first loaded when testing for the libz version, the problem results in 
the above symptom.

The good news is that the former problem can be circumvented by not 
specifying the "CXX=" parameter at all.

The story would have come to an end right here, had I identified this as 
the root cause of problems; however, by the time I had tried without the 
"CXX=" parameter but with "--enable-static", I had already messed up the 
boost-related parameters.

One version included trying to compile without any of the boost 
parameters, which led me to discover another pitfall:

- ./compile is perfectly happy with boost version 1.33, but make needs a 
higher version (I think 1.35).

With boost 1.33 installed in a standard location (in this case 
/usr/include and /usr/lib), the symptom manifests as error messages 
during make, complaining about being unable to find some "boost/*.hpp" 
files (e.g. "boost/unordered_map.hpp").

Now one would think that informing ./configure to search for boost in a 
different directory, using the "--with-boost=" parameter, would solve 
the problem.

The bad news is that with my setup it doesn't. Again it passes 
./configure fine, and now it also passes compilation. However, linkage 
fails with messages like the following:

g++  -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s 
-O3 -ffast-math -mfpmath=sse -msse3 -pthread 
-L/home/clipka/povray-benchmark/install/boost_1_37_0/lib  -L/usr/lib -o 
povray  disp_sdl.o disp_text.o ../vfe/libvfe.a 
../source/backend/libbackend.a ../source/frontend/libfrontend.a 
../source/base/libbase.a ../source/libpovray.a  -lSDL -L/usr/lib -lSDL 
-lX11  -ltiff -ljpeg -lpng12 -lz -lrt -lm -lboost_thread  -pthread
../vfe/libvfe.a(unixconsole.o): In function `main':
unixconsole.cpp:(.text+0x1700): undefined reference to `vtable for 
boost::detail::thread_data_base'
unixconsole.cpp:(.text+0x18ab): undefined reference to 
`boost::thread::start_thread()'

It appears to me that for some reason the linker still looks for the 
boost_thread library in the standard directories first, where it will 
find the boost 1.33 library, but obviously fail to link the program 
against it due to the version incompatibility.


In the end, it has taken me some time (and some swearing and cursing) to 
come up with the following sequence of commands that works fine:

./configure                    \
     --prefix="${install_dir}"  \
     --enable-static            \
     --with-boost="${install_base_dir}/boost_1_37_0" \
     --with-boost-thread="boost_thread-gcc41-mt-1_37" \
     --disable-debug            \
     --enable-optimize          \
     COMPILED_BY="Christoph Lipka"

make check
make install

As a matter of fact, the version number ("-1_37") at the end of the 
"--with-boost_thread=" parameter does not seem necessary with my setup; 
however, there may be a caveat here: My 1.33 installation of boost does 
not feature a "libboost_thread-gcc41-mt.a"; I guess if it did, the 
linker would again find that before going on to look in the 1.37 boost 
installation.


Well, so much for my adventures trying to compile POV-Ray 3.7.0 on my 
Unix machine with the GNU compiler suite. I hope this account may help 
someone some day.

Another caveat: I haven't been able to convince ./configure to enable 
X-Window support. According to the messages in config.log, it may be 
necessary to use dynamic linking to this end, which of course brings me 
back to the issues with boost.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.