Le_Forgeron <lef### [at] freefr> wrote:
> Le 21/06/2011 12:46, Jan-Philip Gehrcke a écrit :
> > Le_Forgeron <lef### [at] freefr> wrote:
> >> Do you have X11 running ?
> >> ("make check" expects to open a X window and render biscuit.pov... )
> >>
> >> rendering of biscuit.pov is rather short, and you have to click on the
> >> window to exit povray once rendered.
> >>
> >> Can you interrupt ?(ctrl-c)
> >> And retry ?
> >
> > Quick response :-)
> >
> > Oh.. yes, I am running X11 and there does not open up any window during 'make
> > check'. Ctrl+C and TERM did not work, I had to use SIGKILL (at first on 'make
> > check' and then on povray because it daemonized).
> >
> > I now retried 'make check' and observed the same behavior. While povray hangs,
> > it does not show up in 'xlsclients' nor in 'netstat -nlp'
> >
> > Any further suggestions? Is it a problem that povray does not find its
> > configuration file, as stated in the big log file in the opening post (it should
> > do well without, shouldn't it?)?
> >
> >
>
> The missing configuration file is not an issue.
>
> It should continue like:
>
> > ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 +a0.3
+L./include
> > povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is
discouraged.
> > povray: cannot open the system configuration file
/home/grimbert/povray37/etc/povray/3.7/povray.conf: No such file 
or directory
> > Persistence of Vision(tm) Ray Tracer Version 3.7.0.RC3 (g++ 4.4.3 @
> >  x86_64-unknown-linux-gnu)
> > This is a release candidate of POV-Ray version 3.7.0.
> > General distribution is strongly discouraged.
>
>
> Now, you are on a system which insist on putting 32 bits libraries in
> /usr/lib despite it being a 64 bits system...
>
> The 100% CPU is strange too. But I tested only with boost 1.40 installed
> on system.
>
> What does "ldd unix/povray" provides ?
> (any missing or strange libraries ?)
> Have you checked LD_LIBRARY_PATH environment variable ?

Yes, I've checked LD_LIBRARY_PATH and it is/was set to the directory where my
libboost_thread.so (1.46.1) is inside. Now, let's compare our ldd outputs.

differing versions (me):
libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00007f42aa14c000)
libboost_thread.so.1.36.0 => /usr/lib64/libboost_thread.so.1.36.0
(0x00007f42a98e5000)

differing versions(you):
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00007fa126736000)
libboost_thread.so.1.40.0 => /usr/lib/libboost_thread.so.1.40.0
(0x00007fa125ecc000)

only in my config:
libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f42a89fb000)
libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f42a87f3000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f42a85e9000)
libxcb-xlib.so.0 => /usr/lib64/libxcb-xlib.so.0 (0x00007f42a81e2000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f42a7fc6000)

only in your config:
libasound.so.2 => /usr/lib/libasound.so.2 (0x00007fa124e9b000)
libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007fa124a13000)
libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007fa124809000)
libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007fa1245f0000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fa1241ce000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fa123dc3000)

I've removed duplicates. Is there anything very suspicious in these differences
being responsible for my error?

The first insight for me is that my system insists on
using the libboost_thread.so.1.36.0 although libboost_thread.so and
libboost_thread.so.1.46.1 are in my LD_LIBRARY_PATH. I am wondering why
povray is specifically searching for the version 1.36.0? Was this fixed during
compile time (how does that make sense, configure says: checking for boostlib >=
1.37... yes?)?.

Anyway, I worked dirty around this problem by

ln -s /home/bioinfp/jang/apps/lib/libboost_thread.so.1.46.1
/home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0

Then ldd finds this link:

libboost_thread.so.1.36.0 =>
/home/bioinfp/jang/apps/lib/libboost_thread.so.1.36.0 (0x00007fcc628bc000)

and by following this link actually uses libboost_thread.so.1.41.1.

But still the same misbehavior during make check as above. Can we now be sure
that this issue is not libboost_thread related?

Jan-Philip

Post a reply to this message