|
 |
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
|
|
|
|
clipka schrieb:
> 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.
I finally got it to work, using the following commands:
LD_LIBRARY_PATH="${install_base_dir}/boost_1_37_0/lib"
export LD_LIBRARY_PATH
./configure \
--prefix="${install_dir}" \
--with-boost="${install_base_dir}/boost_1_37_0" \
--disable-debug \
--enable-optimize \
COMPILED_BY="Christoph Lipka"
make check
make install
Caveat is that LD_LIBRARY_PATH must also be set whenever running
POV-Ray. Care should also be taken in case LD_LIBRARY_PATH is already
set for other purposes (in this case the path to the boost lib directory
should be prepended or appended, separated with a colon, i.e.:
"${install_base_dir}/boost_1_37_0/lib:${LD_LIBRARY_PATH}" - unless it is
already contained in LD_LIBRARY_PATH of course...)
Post a reply to this message
|
|
|
|
clipka wrote:
> I finally got it to work, using the following commands:
Good work there, and thank you very much for posting your notes. It had just
the hints I needed to get it all working here: dynamic linking AND X-windows
support, using both the gnu and intel compiling toolsets.
I resorted to renaming the boost .so file I compiled so it would be unique on
the system, and specifying that name for --with-boost-thread. Then I set
LD_LIBRARY_PATH to nothing but the path to the boost stuff, and configured by
specifying all the other --with-library paths manually.
After all that, it runs fine on the login node, but the compute nodes in the
cluster don't even have access to any X-windows libraries unless I copy them all
over to my home directory. Since I really don't want to risk accidentally
running on these without -D anyway, I might just stick with the
statically-compiled executable except for noodling around on the head node.
Thanks again!
~David wagner
Post a reply to this message
|
|
|
|
clipka wrote:
> Caveat is that LD_LIBRARY_PATH must also be set whenever running
> POV-Ray. Care should also be taken in case LD_LIBRARY_PATH is already
> set for other purposes (in this case the path to the boost lib directory
> should be prepended or appended, separated with a colon, i.e.:
> "${install_base_dir}/boost_1_37_0/lib:${LD_LIBRARY_PATH}" - unless it is
> already contained in LD_LIBRARY_PATH of course...)
yeah, LD_LIBRARY_PATH is one of Linux magic words I use the most. :)
when you first know of it, you feel suddenly shinning... ;)
Post a reply to this message
|
|
org> wrote: